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=4447&dsMessageId=12685 71 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1317101
