Hi Stian and Adam, This is indeed a very interesting topic. In the past, a similar mapping from Resource to URIs was already suggested, reusing the same declarations used by the Router.
Like you I agree that this is a common need but I'm not really sure yet how to support this in the API, and in an efficient way. Sometimes several URI templates can lead to the same Resource so this adds even more complexity. As for the URI lists, there is already a o.r.d.ReferenceList class that you can leverage to generate "text/uri-list" representations. In term of standard for resource lists, I think that WADL could be a good choice, which I tend to view as an hypermedia content type, programmatic alternative to HTML. Best regards, Jerome > -----Message d'origine----- > De : Adam Taft [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 14 juin 2007 01:54 > À : [email protected] > Objet : Re: Generating URIs for resources > > Stian, > > Great question / conversation starter... > > You're right, this seems to be a common problem that every REST > developer has to work with. Having some level of support for > resource > list generation in RESTlet would be nice. > > I don't really have any new ideas for you, as I have to > generate my own > list of resource urls in application code. I think it might > be hard for > a library to know enough about the application to correctly generate > urls for it. Some sort of callback interface would be > required for this > to work. > > At a minimum, I think it would be nice for the library to be able to > generate lists of resources in "text/uri-list" format, which is one > resource url per line. Something like: > > HTTP/1.1 200 OK > Content-Type: text/uri-list > Content-Length: 12345 > ETag: generated by List.hashcode() > > http://.../users/jane > http://.../users/john > http://... > > The advantage here is that you're using a defined "standard" content > type that has predictable usage and results. > > The disadvantage, of course, is that you don't know some nice to have > additional information about each linked-to resource. For > example, you > don't have the 'name' field (in your example, Jane) in the listing. > Thus a user agent doesn't have much to display except for the > url itself. > > When I get a listing from the server, I want additional > details for each > resource. As such, I have defined my own common data transfer object > called an Entity that I use when generating lists. Included in the > Entity object are these fields: url, key, last modified, > etag, display > text (like 'name') > > The biggest point to see here is including information about the etag > and/or last modified information on the resource. That way, when the > client performs a GET request for the individual resource, > the correct > "If" condition can be added to the HTTP request which allows > good caching. > > Caching is very important, and so having this information > available as > part of the list is critical. I don't want to have a list > returned of > 100 resources and have to fetch each one. It's quite likely that the > user has already requested these resources before. (Note > also the use > of Etag in the example above). > > I honestly don't think there is a "content type" which adequately > addresses the above requirements. The text/uri-list content type is > only a CRLF delimited URL listing. However, perhaps we can > extend the > standard usage of text/uri-list by adding the above > functionality. This > additional functionality could be denoted by a parameter to > the content > type. > > Here's the above example in this new format... > > HTTP/1.1 200 OK > Content-Type: text/uri-list;expanded > Content-Length: 12345 > ETag: generated by List.hashcode() > > http://.../ ETag=${etag} Last-Modified=${last modified} > Display=${display} > http://.../ ETag=${etag} Last-Modified=${last modified} > Display=${display} > http://.../ ETag=${etag} Last-Modified=${last modified} > Display=${display} > > Note, the above should be all on one line, not separate word wrapped > lines. This example uses a ";expanded" parameter to the content type. > > If you go with XML, you're going to have a harder time pegging a well > defined mime type to use. But, that's not to say your can't > create your > own in the x-* space. For example: text/x-xml-resource-listing or > text/x-xml-uri-list or whatever. > > If the results are going to be XML based, then using XLINK makes very > good sense. I don't think xlink has a strict definition for anything > like "etag" or "last modified," but of course that's not to say the > generated XML can't have these fields in it. > > Anyway, the WHOLE POINT of my message is that once you have defined a > standard representation for a list of resources, then you are on your > way to figuring out how to implement it in Restlet code. > Without having > that "standard", I don't think it's even something that can/should be > touched within the api. I think the RESTlet crowd pushing > forward on a > standard solution to this is ok, but likely there are other places > which this question should be posed. > > Have you contacted the rest-discuss list for any solutions to > this? Has > there been any standards that have emerged for generating lists of > resources yet? Maybe you should cross post and see what > advice you get > as well. > > Adam > > p.s. The reasons you should be using Spring are for what > Spring brings > to the table. Ie. lots and lots of helpful and practical development > tools for middle-ware applications. The whole rant of Spring > integration with Restlet is obviously another discussion > which has been > brought up before. For real world application development, > Spring is a > winner and is used by thousands (if not hundreds of thousands) of > projects. Every time I go looking for a tool, I seem to find a good > solution in the Spring tool box.
