Hi Markus,
> My questions is: What is the optimal URL schema for this?
Again, as already mentioned in another mail, I'm neither an expert nor
do I have years of experience in developing RESTful applications.
The URI design of your application is basically linked to your question
about "RESTful Documents".
In my opinion you should publish the characteristics as individual
resources if they are more complex than simple key-value data (e. g.
length, diameter as mentioned in your other mail). In this case I would
choose a URI template similar to your first variant:
http://example.com/systemroot/parts/{partId}/characteristics/{chId}
If you want to use other attributes than the primary key(?) to identify
the part or the characteristic, you could use a URI template like this:
http://example.com/systemroot/parts/{partAttribute}/{partAttrId}/characteristics/{chAttribute}/{chAttrId}
This however, will only allow to specify one attribute at a time and can
not be compared to the power of a full-fledged query language like SQL.
If you need to have a more dynamic ability to specify your search
parameters, you could use a URI template like
http://example.com/systemroot/parts?{attr1}=...&{attr2}=...
and then return a list of matching resources (of course with proper
links to the URI of the parts) or if it takes longer to compute the
result just send a "202 Accepted" and the URI of the search result in a
"Location" header to the client (e. g.
http://example.com/systemroot/searchResult/{Id}).
Again I'd recommend to grab a copy "RESTful Web Services"[2] which also
says a thing or two about URI design and how to handle some of the
requirements you mentioned.
Concering your variants 3, 4 and 5 for the URI template, I would really
not use them since they kind of violate the principle of hierarchical
identifiers[3] which URIs were meant to be.
It simply does not make sense to have a characteristic without a part
which possesses this attribute.
[1]:
https://jersey.dev.java.net/servlets/ReadMsg?list=users&msgNo=6110
[2]:
http://oreilly.com/catalog/9780596529260/
[3]:
http://www.ietf.org/rfc/rfc3986.txt Section 1.2.3
Regards,
Jochen
Markus Karg schrieb:
> Some ideas to address a particular characteristic which all are working
> but might not be optimal:
>
>
>
> (1) http://myhost/systemroot/parts/{PartID} /characteristics/{ChID}
>
>
>
> (2) http://myhost/systemroot/parts;ID={PartID}/characteristics;ID={ChID}
>
>
>
> (3) http://myhost/systemroot/{ChID}
> <http://myhost/systemroot/%7bChID%7d> with
> Accept=application/characteristic+xml and ChID being unique.
>
>
>
> (4) http://myhost/systemroot?type=characteristic;id={ChID}
> <http://myhost/systemroot?type=characteristic;id=%7bChID%7d> and ChID
> being unique.
>
>
>
> (5) http://myhost/systemroot/{ChID}
> <http://myhost/systemroot/%7bChID%7d> and ChID beeing globally unique
> (i. e. parts and characteristics share one address room)
>
>
>
> (6) ...not addressing the characteristic at all but contain all
> characteristic directly in the part's XML
>
>
>
> Obviously there are lots of solutions, but I could imagine that after
> years of RESTfulness, the experts might have identified one that is
> optimal. But which one is it? And, the problem gets more complex if you
> don't want to give the ID but query by a different attribute like
> "displayName" -- how to make up a URL which could serve both cases...?
>
>
>
> Any comments welcome!
>
>
>
> Regards
>
> Markus
>
>
>
>
>