I was thinking about this a little over the weekend. I wonder if we should have two approaches:
1. There appears to be a common pattern for simple resource REST services where you just have CRUDE operations and there's a single collection (the collection has a URI and so do each of the items in the collection). This is how RSS, Atom, and simple REST and simple database scenarios work. 2. There is then the more complicated world where the URIs specify resources which are perhaps more complex queries or are resource joins (e.g I want the contact and address details for people in New York state). Not sure how you'd express that :-o http://...../Contacts.php/contact/address?state=New%20York . Perhaps for this world we just provide a CRUD interface and then it's up to the implementor to interpret the URIs. Doesn't feel particularly helpful, but we might then spot patterns for other REST styles which can then be encapsulated in new bindings or helper functions. Graham. On 7 Jun, 17:42, Graham Charters <[EMAIL PROTECTED]> wrote: > On 7 Jun, 16:10, Matthew Peters <[EMAIL PROTECTED]> > wrote: > > > I'm glad you like the idea, and you ask a good question. It has always > > seemed to me that right at the bottom we have service-oriented > > components and resource-oriented components, and that the service > > oriented ones can all be totally different but that at one level the > > resource-oriented ones are all the same - there should be a CRUD > > component at the top/bottom from which they all inherit, and > > rest.resource inherit from that. What useful shared logic it could > > have I don't know - perhaps it is just an interface i.e. method > > signatures and constants. > > I mostly agree with this, and for basic resource-oriented services > CRUD (should probably be CRUDE because we typically need an Enumerate > (aka list) capability) would suffice. Atompub is a good example > here. Also, a basic REST CRUDE could be used to provide simple REST > access to databases. > > However, I think in many REST scenarios, there are more capabilities > we need to support. I find the REST presentation by Joe Gregorio > (seehttp://bitworking.org/projects/rest/) very enlightening. The example > he shows at the end (slide 50http://bitworking.org/projects/rest/50.html) > has quite an elaborate set of URIs the likes of which we will probably > need to be able to support. The resource in this example is Accounts > for a review service. It would be good to start with an example like > this and see how it would map down to an SCA component with a REST > binding. I think chances are we will end up with more methods than > CRUDE. > > Regards, Graham. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
