Hi Alexander,
I think you did a good job of summarizing the pros and cons. Now, REST
itself doesn't provide any guidance on that point. It's partly a matter of
taste.
Using extension names provides very clean and compact URIs. However, using
sub-resources provides more flexibility. You could even have this scheme:
- http://localhost/resource/properties/
- http://localhost/resource/properties/md5
- http://localhost/resource/properties/size
The advantage is that you can retrieve the list of all properties in one
shot, and even 'discover' them...
Regarding JAX-RS extension vs Restlet API, it is partly a matter of taste,
but the Restlet API has a significantly broader features scope. Also Restlet
1.2 will introduce its own support for annotations (more focused than
JAX-RS). If standards compliance is high on your priority list, using JAX-RS
extension is a good choice.
Finally, you can retrieve the Restlet's request/response in the JAX-RS
extension. For example using Request/Response#getCurrent() static methods.
From that you can retrieve/update the HTTP headers if needed. See also the
org.restlet.engine.http.HttpRequest/HttpResponse classes for header helper
methods (in recent Restlet 1.2 snapshots).
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : Alexander J. Perez Tchernov [mailto:xas...@gmail.com]
Envoyé : mercredi 4 mars 2009 22:14
À : discuss@restlet.tigris.org
Objet : how to expose meta information
Hello. I want to ask if the following design is ok from the REST / ROA
point of view, and if it would be easy to realize these schema in restlet
(and preferable with JAX-RS ext).
Let we have some resources and meta information (size, creation date,
expiration date, md5, grddl) associated with each of them.
Each of these resources will be accessible through regular permalink
http://localhost/resource, and meta information probably will be exposed
through specific headers (ETag/expire + customs lines ). I suspect that some
clients (AJAX mainly) would need to access these meta information as well,
but I suppose that AJAX would fail with manipulation and analyzing headers
(or it will require very specific libraries). Thus I want to expose this
meta information in such a way, that AJAX can fetch (or update) them using
regular GET / POST / PUT methods.
I have several choices to accomplish this objective. The first one is to
publish meta information as sub resource like http://localhost/resource/md5,
or with special convention like http://localhost/resource/!md5. The second
one is to absorb media types notion and expose resources in a strange manner
like http://localhost/resource.md5, http://localhost/resource.size. The
third choice is to use querying like http://localhost/resource?md5,
http://localhost/resource?size
Actually I'm against querying, since size|md5|expiration|security data of
the resource are the resource itself (although they are usually calculated,
they may be explicitly changed BY the author), while querying is for non
solid things. To be honest, I'm against
resource.md5 schema too, but I was got an argument that if user download
the meta information file (for example the GRDDL script that extracts the
RDF from the original resource), he would definitely got the
C:\resource.grddl file stored on his file system, instead of having
C:\grddl file with no prepended resource name if we will choose the first
subresource schema (resource/md5) approach. I'm really think that /#
schema is good one, but I'm afraid that this complicates things.
Do you have any recommendation how to design this (which approach to
choose) to be compatible both with REST and AJAX clients? I know that REST
claims to either publish meta info in HEADers or include them directly in
resource (if it's HTML representation), but i want to allow to fetch and
manipulate with meta information bypass original resource.
By the way, does JAX-RS support to publish custom HEADERS or it's better to
migrate to regular restlet? Actually I don't remember any examples on this.
--
Best regards,
~ Xasima Xirohata ~
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=12685
71
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1317101
