Intro

The way kauri handles wiring and m12n (modularization) through the export/import of so called rest-services suggests we should think about interchangeability of service-implementations and thus some standardization of certain services.

Looking at the benefits of  having the interchangeable 'mock' and 'JPA' implementations in our own "database resources" module it seems obvious an even bigger advantage could be get from a broadly recognised uniform way of dealing with this kind of resources.

Even if such goal turns out to be unreachable or unwanted, I have the impression a lot of recurring patterns can be listed and covered. Maybe finding standard ways to cover those more micro-level issues in a way they can be combined can prove a viable alternative. Opinions welcome.

For the 'REST' die hards the above 3 paragraphs contain probably enough blasphemy already.  Correct reading of the rule of Rest/URI opacity should probably explain how this effort (which I admit has a pragmatic drive doesn't need to be un-ReST-full. The drive behind having any standard URI pattern is about needing lesser documentation, higher reuse of terms, patterns, possibly (partial) solutions leading to faster development, lesser surprise.  The danger of breaking the opacity rule is in the fact that clients would start implementing the standard, and making assumptions they shouldn't.

So while admittedly the REST purity is not the primary goal here. Still there is no conflict if we allow ourselves allong the path of pragmatics to list up all aspects to be covered so the appropriate representation-formats can be discussed that can lead to the more RESTy grail of clients being able to adapt themselves flexibly to servers that decide to follow different URI schemes.

Obviously I hope much of this kind of efforts already exist outside, so we can just comply to what is out there.  Please let us know if you know about any related activities.

Reading  Material

Stuff read sounding like it runs around the same idea:

[mf-rest-url]  http://microformats.org/wiki/rest/urls
This follows the path taken by what Ruby on Rails is doing ( see also the reference to http://topfunky.com/clients/peepcode/REST-cheatsheet.pdf)
Noted stuff:

  • method tunneling via '_method' rather then the 'method'  we inherit from Restlet
  • includes following a relationship
  • includes POST to trigger operations
  • suggests being explicit about file formats using extension suffix (none suggesteing 'default')
  • mixes pure dataservice with UI/management a bit:
    • assumes GET /{entity-type}/new to produce a form to create new entity of type
    • yet unclear if the GET /{entity-type}/{id} should also return a form to allow update, and if not where that should be found then

[ug-unrestricted] http://escher.elis.ugent.be/publ/Edocs/DOC/P108_165.pdf
Balance between well researched and practical oriented attack to the problem. Not publically available: copy upon request.
Noted stuff:

  • Academic ring
  • Serious effort in writing up a serious motivation (more then the 'feeling') for having a lightweight common protocol
  • Points out the conflict between 'large-complex queries' and the expressiveness of URI + request parameters
    • But takes the somewhat unconventional route of using WEBDAV's REPORT method as an alternative to GET that allows an entity-body

Interested in finding more other references ans work, please share on the mailing-list, or leave a comment.

To-read-list (growing)

Other related stuff

Obviously formal ways to describe the ins and outs of rest-services are likely to be essential in this effort.

Issues and Patterns

Listing allready a number of recurring issues that go beyond the most naieve and basic.  Hoping these will lead to some standard

Query Parameters
FullText/Single Word Querying
Structure (QBE) Querying
Browsing
Pagination
FacetBrowsing
BlobReferencing and uploading
Locking
Transcations