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.
