Given the code fragment: Which URL triggers the invocation of the getEmployee () method?

The correct answer is B. <base url>/Employees/J6349. Option B is correct because the code fragment likely uses a JAX-RS @Path annotation with a regex-constrained path parameter such as @Path("/Employees/{id: [a-zA-Z][0-9A-Za-z]}"), which requires the ID segment to begin with a letter - J6349 satisfies this pattern. Option A…

Implement REST Services using JAX-RS API

Question

Given the code fragment:

Which URL triggers the invocation of the getEmployee () method?

Exhibit

Options

A<base url>/Employees/89724
B<base url>/Employees/J6349
C<base url>/Employees/id:a7280
D<base url>/Employees/id/J6349

How the community answered

(27 responses)

A
4% (1)
B
74% (20)
C
7% (2)
D
15% (4)

Explanation

Option B is correct because the code fragment likely uses a JAX-RS @Path annotation with a regex-constrained path parameter such as @Path("/Employees/{id: [a-zA-Z][0-9A-Za-z]*}"), which requires the ID segment to begin with a letter - J6349 satisfies this pattern.

Option A (89724) fails because it is purely numeric; a leading-letter constraint rejects it. Option C (id:a7280) includes a literal colon in the URL segment, which does not match a simple {id} placeholder - the colon is not part of the path template syntax. Option D (id/J6349) introduces an extra path segment, so it would only match a pattern like @Path("/Employees/id/{id}"), not @Path("/Employees/{id}").

Memory tip: Think of the regex as a bouncer - only IDs that match the pattern get through the door. When you see a constrained {param: regex} in JAX-RS, immediately ask "which answer value satisfies the regex?" and eliminate anything that breaks the URL structure first (wrong number of segments or illegal characters), then apply the regex to the remaining candidates.

Topics

#JAX-RS path patterns#path parameters#URL routing#REST endpoint mapping

Community Discussion

No community discussion yet for this question.

Full 1Z0-900 Practice