Algermissen <[EMAIL PROTECTED]> wrote:
>
>
> On May 21, 2006, at 6:58 PM, Mike Glendinning wrote:
>
> > but I still think that REST would benefit from a simple but
> > machine-processable way of defining exactly what resource
> > representations will be exchanged ("types" and "messages") for
each
> > of the "operations" allowed (GET, POST, DELETE, PUT) on a
particular
> > resource identifier ("service").
>
> But this would introduce a kind of coupling REST deliberately
chose
> to *avoid* therby enabeling the service to evolve and especially
to
> change the exact representations it sends. Surely this demands for
> client implementations that can handle this scenario but that is
> after all the cost of the better evolvability.
>
> Or am I missing your point?
>
> Jan
>
Erm, the addition of a formal service description does not affect
the "loosely coupled" or "tightly coupled" nature of a service (which
is a separate topic). The service description merely describes the
service as it exists, it does not *change* any attributes of the
service.
As we've been discussing, in practical implementations of REST the
client and server are extremely tightly coupled because the
representations cannot change without you rewriting your client or
server application code.
You can try and be clever about the kinds of changes you expect and
code for those in advance, that is be "liberal with what you
receive", but you won't catch everything in this way. There is also
no reason why code automatically generated from a service description
could not take the same approach (e.g. build in a bit of flexibility
and looseness of processing).
Ideally, of course the service description will provide ways to
specify the messages exchanged by a service and how they are likely
to evolve, that is provide guidance on what assumptions should and
should not be made by clients.
By *not* formalising such a service description, each client will
take its own view of evolvability and [probably] make a different set
of assumptions about future changes. When a client is dealing with
hundreds of different services from different suppliers (e.g. in a
SOA) this is clearly a recipe for complexity and chaos.
One of the main goals of service description therefore is to surface
these hidden assumptions for the benefit of interoperability and
manageability. I agree that we don't have a good language for doing
this yet, but that is what I am proposing needs to be created.
-Mike.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
