spring - Behaviour of REST service using HTTPServletRequest and using @PathVariable -

below 2 scenarios came across while coding services project in school.

scenario 1

@requestmapping("/customer/firstname/") public customerrepresentation getcustomersbyfirstname(httpservletrequest request) {     string name = request.getparameter("fname");     list<customer> customer = customeractivity.findbycustfirstname(name);     // etc } 

scenario 2

@requestmapping(value="/customer/firstname/{fname}",method = requestmethod.get, produces = {"text/html","application/json", "application/xml"}) public @responsebody list<customerrepresentation> getcustomersbyfirstname(@pathvariable("fname") string name) {     list<customer> customer = customeractivity.findbycustfirstname(name);     // etc } 

behaviour:

1. if use first approach, able access results using link browser , postman.

2. if use second approach, able access results using postman when specify accept headers. if use browser gives me error 406, type not supported.

3. using client both working fine minor modifications url.

what causes this? assume default settings in httpservletrequest? if use second approach, how websites function, or doing wrong?

these 2 uris different on principle, , shouldn't considered same @ all.

first, there's huge difference between path variable , query parameter - path variables required part of path, or path won't accessible. it's difference in these 2 uris:

/customer/firstname?fname=bob /customer/firstname/bob 

you can't access second uri without bob, opposed first uri; may asking other fname.

second, reason have have accept headers set due way produces array set up: have text/html, application/json, , application/xml; client won't able accept that's not 1 of 3 types.

third, directly answer last question, explicitly discourage second approach because of way path variables should partitioned. path describes information required request continue; here, you're asking information customer, should contained query.

in vein, request uri should really customer query firstname.

/customer?firstname=bob