users@jersey.java.net

Re: [Jersey] Optional PathParam is it possible?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 19 Feb 2010 09:41:25 +0100

On Feb 19, 2010, at 3:35 AM, Dário Abdulrehman wrote:
>
> My gut feeling is that you are placing stuff in the URI that may be
> better as part of a representation.
>
> For example a client could POST to a resource with details of the
> tfs genes and evidence_codes. The resource returns a 201 created
> with a URI from which data can be retrieved. This naturally requires
> more work on the server to maintain created resources (however you
> can retain stuff in memory if you so wish as it may not require
> persistent storage, and then it becomes much easier)
>
> However this would remove the statelessness from the operation since
> I would need two requests to perform a single operation: one POST to
> provide the data and one GET for the results.

Right, you require more resource state, and it does require the client
make two requests.


> I don't know if this presents any disadvantage for the clients but
> otherwise it seems to be a nice solution.

I guess it depends on your application and how the "query" information
might evolve over time.


> So you are suggesting that I provide a representation of the data
> i(n JSON for example) via POST?

Hard for me to say that is the right solution for your needs. I am
just presenting possible RESTful solutions using Jersey that have pros
and cons. Since i do not know the extent of your application i cannot
evaluate what would be the best thing if i was designing the whole
application :-)


>
>
> Alternatively it might be better to embed a bit of JSON as a path or
> query parameter, which is possible as long as the JSON is encoded
> correctly (it will make for ugly URIs :-) ).
>
> Then you can easily extract it out using JSONObject:
>
> @GET
> @Path("{id}")
> public .... get(@PathParam("id") JSONObject o) { ... }
>
> The reason this can work is because the JSONObject has a string
> constructor.
>
>
> This could work but isn't the purpose of the GET to obtain a
> representation from a resource instead of sending a similarly
> complex representation?
>

If you place the stuff in the path or query i think it is OK as long
as you describe appropriately how the client can construct the URI.
Using query parameters is better in this respect because you can
easily use HTML forms and document the query parameter required. Using
a path parameter IMHO requires the use of URI templates to be
hypertext driven.

I have seen a number of services that provide their own syntax as part
of a path or query parameter. The link you include below adds to that
number :-) note that the gdata spec is advocating explicit URIs rather
than defining hypertext and a looser coupling between the client and
server. That may be OK for your needs but it is important to call out
the distinction.

You might want to ask general REST questions about your requirements
on rest-discuss:

   http://tech.groups.yahoo.com/group/rest-discuss/

Paul.