rest resource binding?

[simonslaws-gM/Ye1E23mwN+]

I think that it would be interesting to have a "rest resource" binding
to sit alongside the rest rpc binding. The intention would be to
provide a convenient template against which to construct a service
which is able to provide an implementation for the HTTP style Create
(POST), Retrieve (GET), Update (PUT), Delete (DELETE) style verbs. The
resource identification would rely on normal URL path info and
parameter information.

I'm not convinced that the terms rest rpc and rest resource are good
terms for these bindings. Maybe http rpc and http resource would be
less controversial.

I'm just doing a bit of documentation at the moment as I notice that
we are bit lacking on docs for the other bindings but when done I
think I'll give this a spin. I'm mentioning it now in case anyone has
any thoughts.

Regards

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Caroline Maynard]

Post by simonslaws-gM/Ye1E23mwN+
I think that it would be interesting to have a "rest resource" binding
to sit alongside the rest rpc binding. The intention would be to
provide a convenient template against which to construct a service
which is able to provide an implementation for the HTTP style Create
(POST), Retrieve (GET), Update (PUT), Delete (DELETE) style verbs. The
resource identification would rely on normal URL path info and
parameter information.
I'm not convinced that the terms rest rpc and rest resource are good
terms for these bindings. Maybe http rpc and http resource would be
less controversial.

Ooh, a controversy. Where?

You haven't discussed the body type for this binding. Is this just a
pass-through mechanism, with the intention of allowing it to be extended
for specific encodings?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

Yes, I had imaginged that it would be a pass through mechanism of
sorts. There has been some work on dealing with specific fixed
formats, for example, RSS and ATOM, in the REST environment in SCA. So
you could consider these to be representative of bindings that deal in
concrete and fixed body types. I'm not suggesting that they are
repurposed in any way just put them up there as a contrast.

I don't know how the path info/body information should be presented. I
Assume that there are limited types of data that can arrive in the SCA
scenario

GET
Params on URL
POST
Form params on URL or Body (x-www-form-urlencoded)
XML in body (xml)
PUT
Form params on URL or Body (x-www-form-urlencoded)
XML in body (xml)
DELETE

We could take take the view that the CRUD interface is generic and
that we need to be able to pass this data into each method in a
generic way, e.g. parameter arrays, stdclass, generic SDO, simpleXML
etc. I'm also interested in allowing people to use SCA to define what
type they are expecting. Maybe this sits between being a pass through
and a specific encoding. I.e. it's a specific encoding for a
particular service but the binding is not restricted in the types on
encoding that can be specified.

On the return we need to allow either a simple or complext type to be
returned. In this case I think we can take the approach we have taking
before of allowing simple types or SDOs to be returned.

The other thing we need to support is the various HTTP error codes
that can be generated.

Thoughts?

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

I really like the way that Graham has used inheritance to create the
ebaysoap binding as an extension of the soap binding. I have not
looked at the detail in these posts but as soon as you said "template"
and "alongside" right at the top of the first post I wanted to suggest
that inheritance should be used.

Matthew

Post by simonslaws-gM/Ye1E23mwN+
Yes, I had imaginged that it would be a pass through mechanism of
sorts.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

Its a good analogy. We could consider the resource binding to be the
parent of other bindings that apply particular sematics or data
formats over and above the basic ability to call the CRUD methods at a
particular endpoint.

Do you think there is a more fundamental binding that this
rest.resource binding should inherit from?

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

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.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

Post by Matthew Peters
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 (see
http://bitworking.org/projects/rest/) very enlightening. The example
he shows at the end (slide 50 http://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-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

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.

Post by Graham Charters

Post by Matthew Peters
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-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Matthew Peters]

I like the idea of walking one step at a time towards the goal, so
that we do the simple case well at first. You say "two approaches", I
hope they are really one approach, but one more elaborated than the
other, so two steps down the same road, not one step each down two
separate roads. That's never comfortable :-)

Post by Graham Charters
I was thinking about this a little over the weekend. I wonder if we

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[simonslaws-gM/Ye1E23mwN+]

I agree with Matthew's sentiment. I think we have enough ideas here to
have a crack at the simple CRUDE case. I view the second case as being
similar to the first case but with more complex URIs. I think it is
useful to point out that this extra complexity is required in reall
applications (which Joes presentation that Graham references makes
clear) but I think it's something we should consider as an extension
to the simple case.


Regards

Simon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

[Graham Charters]

I referred to two approaches because I felt that the two 'interfaces'
might not be progressive (i.e. steps down the same road). I suppose
in some abstract way I could be wrong in that the path info in the
URIs is an 'identity' in both cases (e.g. http://..../Collection.php/12
versus http://..../Collection.php/part/5/subpart/15). If the first
case the identity passed to a retrieve, say, could be 12 and in the
second it could be part/5/subpart/15.

+1 for doing the simple CRUDE first :-)

Post by simonslaws-gM/Ye1E23mwN+
I agree with Matthew's sentiment. I think we have enough ideas here to
have a crack at the simple CRUDE case. I view the second case as being
similar to the first case but with more complex URIs. I think it is
useful to point out that this extra complexity is required in reall
applications (which Joes presentation that Graham references makes
clear) but I think it's something we should consider as an extension
to the simple case.
Regards
Simon

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---