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:///C
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
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 nev
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
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 tota
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 al
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
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 shoul
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 typ
[EMAIL PROTECTED] 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
10 matches
Mail list logo
