rest resource binding?

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

simonslawsgooglemail.com wrote:
> 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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Jun 6, 9:59 am, simonsl...googlemail.com wrote:
> 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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

On 7 Jun, 16:10, Matthew Peters <matthew.f.pet...googlemail.com>
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 (see
http://bitworkin
g.org/projects/rest/) very enlightening.  The example
he shows at the end (slide 50 http://bi
tworking.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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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 
http://...../Contacts.php/contact/address?state=New%20
York .  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 <gchart...googlemail.com> wrote:
> On 7 Jun, 16:10, Matthew Peters
<matthew.f.pet...googlemail.com>
> 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://bitworkin
g.org/projects/rest/) very enlightening.  The example
> he shows at the end (slide 50http://bi
tworking.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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

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 

On Jun 11, 8:59 am, Graham Charters <gchart...googlemail.com> wrote:
> I was thinking about this a little over the weekend.  I
wonder if we
> should have two approaches:
>


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

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 phpsoagooglegroups.com
To unsubscribe from this group, send email to
phpsoa-unsubscribegooglegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---