Taking Lisa's mic comments a little further, I'd like to point out that what is in this draft isn't a particularly faithful embodiment of a RESTful service.
In my opinion, a RESTful service would have more resources than are identified in the protocol. Of course, the degree to which anything can be considered "RESTful" seems to be highly subjective. To me, this seems more like XXX over HTTP than a use of HTTP that follows the REST axioms. The question is, whether you are able to model your application (i.e. ALTO) with resources. I'm not sure how that can be done within the constraints that you have, but it seems that more could be done. For instance, included amoung those resources would be indexes, which might solve your capabilities/multiple server problem. That makes the server capabilities discoverable. There might be a combinatorial explosion if you allow for freedom on many axes, but I don't actually think that this is a high risk, given my limited understanding of the current solution. However, if clients are given the ability, as the draft describes, to specify multiple input values to query the database, as is the case with map filtering, then REST is less applicable. Such aspects of the protocol might be hard to fit into a pure resource model. The risk here is that the protocol reinforces client-server dependencies. One potential thing to look at is URI templates, which constrain the form of URIs based on server preferences (rather than client). While it still gives the client greater control over the server than might be ideal, it at least reduces some of the degrees of freedom and (slightly) loosens the coupling. I recommend a little more background reading on REST- you may come to the conclusion that ALTO over HTTP is preferable, or you might find a subset of REST-like capabilities that best fit this. --Martin ...and while I'm at it... I also have to support Lisa's suggestion on content negotiation (on media type) for version negotiation. That works very well, in my experience. It is revealing when you talk about "persisting" responses. That's a caching function and there's good support for that in HTTP. Comments on the mic about JSON and XML and validation were particularly good. The "schema" definition in the document is nice, but hard to use in tools. XML schema has good tool support, which is not necessarily true for the JSON stuff. I'm not up to date on the mapping status between XML and JSON, but I do know that Jersey and JAXB provide these functions. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
