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.
Stuff read sounding like it runs around the same idea:
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)
Balance between well researched and practical oriented attack to the problem. Not publically available: copy upon request.
Interested in finding more other references ans work, please share on the mailing-list, or leave a comment.
Obviously formal ways to describe the ins and outs of rest-services are likely to be essential in this effort.
Listing allready a number of recurring issues that go beyond the most naieve and basic. Hoping these will lead to some standard
FullText/Single Word Querying
Structure (QBE) Querying
BlobReferencing and uploading