users@jersey.java.net

Re: [Jersey] Optional PathParam is it possible?

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Thu, 18 Feb 2010 17:12:29 +0100

On Feb 18, 2010, at 4:51 PM, Dário Abdulrehman wrote:

>
>
> On Thu, Feb 18, 2010 at 9:34 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
>
> On Feb 18, 2010, at 12:40 AM, Dário Abdulrehman wrote:
>
> Given the following resource method:
>
> @GET @Path("tfs/{tf : .*}/genes/{gene : .*}/evidence_codes/
> {evidence_code: .*}")
> public Response doGet(@Context Request req,
> @PathParam("tf") List<PathSegment> tfs,
> @PathParam("gene") List<PathSegment> genes,
> @PathParam("evidence_code") List<PathSegment> ecs,
>
>
> I would like to make each one of the PathSegments optional (tfs/,
> genes/ and evidence_codes/), however like it is now, if I don't
> provide for instance, any genes,
>
> Are they independently optional? if so why not use query parameters?
>
> Or is there a hierarchical dependency? for example if "genes" is
> present then "tfs" must be present? If so may need to be explicit
> and do:
>
> @Path("tfs/{tf : .+}")
>
> @Path("tfs/{tf : .+}/genes/{gene : .+}")
>
> @Path("tfs/{tf : .+}/genes/{gene : .+}/evidence_codes/
> {evidence_code: .+}")
>
>
>
> No they are not independently optional.
>

OK.


> Is it good REST design to represent non-hierarchical data using
> PathSegments?

Hard to say. It may be nothing to do with REST per say and more to do
with modeling. Modeling is hard and i do not know enough about the
information and the relationships to create the model.

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)

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.

Paul.


> An URI suggests a hierarchy but designing a URI path like resource/
> gene1/gene2/gene3.... etc where each gene is at the same level
> breaks that notion or am I being too strict?
> Are there any examples of APIs where this is used?

I do not know of any.

Paul.