0

Is it possible to define path with optional path variables.

like the uri below:

/app/make/{make}/model/{model}/year/{year}/mileage/{mileage}/fuelType/{fuelType}/maxPrice/{maxprice}/transmission/{transmission}/engineSize/{engineSize}

URI may be composed of any 0 or more combinations of the parameters? Is there a way to tell resteasy that all those paths are optional?

cheers.

axtavt
  • 239,438
  • 41
  • 511
  • 482
fmucar
  • 14,361
  • 2
  • 45
  • 50

2 Answers2

3
@Path("/make/{make}{model:(/model/[^/]+)?}{fuel : (/fuel/[^/]+)?}{gearbox : (/gearbox/[^/]+)?}/cars")



app/{make:(/make/[^/]+)?}{model:(/model/[^/]+)?}{year:(/year/[^/]+)?}{mileage:(/mileage/[^/]+)?}

I came up with the above workaround which works but inside the method I need to remove the pathname.

fmucar
  • 14,361
  • 2
  • 45
  • 50
3

Why bother using path segments? If they are optional parameters then it can't be a real hierarchy so why not just use query string parameters. They work much better for this type of parameter.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • Well the requirement docs says so and there other hardware as well using the same syntax of URI so i cant just change it. However, you are right, if it is optional it should normally go into query string parameters. – fmucar Nov 02 '10 at 16:02
  • @fmu One of the main points of the hypermedia constraint is that a server's URI structure is supposed to be a private implementation detail. The fact that you have specs defining what URIs should look like means somebody is planning to write clients that will construct those URIs. That's just plain wrong. You are now faced with the task of convincing your server framework to deal with a URI structure it is not comfortable with, which is completely the opposite to how it is supposed to work. I realize I'm venting at the wrong person, but it felt good anyway :-) – Darrel Miller Nov 02 '10 at 18:55
  • This is a rest application to be used by 3rd party applications as well. If they dont know the URI how are they gonna use it? – fmucar Nov 03 '10 at 08:29
  • @fmu clients in REST systems are only supposed to start with a entry point URL and discover all of the other URLs by looking inside the representations returned from the server. Exactly how a website works. The coupling is on the media type and the rel attribute in the link. – Darrel Miller Nov 03 '10 at 11:12
  • I dont think that is the best of doing it. Imagine hundreds of clients doing request to server. Each time rest server needs to push all the content to client just to filter a couple of them only. First thing is, it does not sound right to send all the possible results to everyone. and the second things is, if rest server sends everything at the beginning then the rest of the filtering should be done on the requesting machine, there is no need to push the filtered content again to the same client. if you see what i mean – fmucar Nov 03 '10 at 12:35
  • @fmu You are partially correct. There is a URI Template spec `http://tools.ietf.org/html/draft-gregorio-uritemplate-04` that tells you how a sever can create a URI template, and if the media-type spec says it is ok, then the client can construct URIs based on the media-type spec and the URI template. It still comes down to what the template looks like is controlled by the server. The client simply fills in the parameters. – Darrel Miller Nov 03 '10 at 13:05
  • I may not have explained it well, the example I gave is not the actual parameters or names. In my case, the uri is built on some specific logic and should be accessed that way. browsing it like a web is not really an option. – fmucar Nov 04 '10 at 21:33