On Thu, Feb 18, 2010 at 4:12 PM, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
> 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)
>
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. I don't know if this presents any
disadvantage for the clients but otherwise it seems to be a nice solution.
So you are suggesting that I provide a representation of the data i(n JSON
for example) via POST?
>
> 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?
> 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.
>
>
I think I found an example here
http://code.google.com/apis/gdata/docs/2.0/reference.html.
In the 'About category queries' section they provide a similar approach for
filtering feeds by category.
Thanks.
> Paul.
>