SOAP, REST, and SOA

[rfo]

Hello Heiko, Paul et al

I'll second Paul's suggestion, but caution that true RESTful approaches
impose the burden of intelligence on the client, making them heavier.
The great news is the server side work benefits from the looser coupling
of course.
A REST-like approach (aka ResourceFul), takes the same resource-oriented
view, but compromises on REST so that it's a bit more like a schema with
4 verbs.  A lot of so-called RESTful interfaces are really ResourceFul.
This approach can also be very effective and makes client work simpler,
but makes them more tightly coupled with the server.  A well designed
URI schema can minimize issues on that front, so you're not stuck with
the old RPC lock step problem.

Some might argue that the looser couple of true REST represents a better
evolutionary model, but a counter argument is that the benefit to the
species is possible only if it does not compromise an individual's
viability.  Forcing developers to build heavier clients might just tip
the scales the wrong way.

In any case, it's worthwhile learning and understanding the benefits of
REST and near-REST approaches.

While on the subject (sorry to hijack your topic Heiko - I'm sure I'll
hear from someone on this), has anyone done any work with SOA and
Eiffel.  It strikes me as a great match, and SOA even talks about
contracts (though not quite so formally as DbC).  I'd love to see an ESB
written in Eiffel, for example, and a set of Eiffel APIs to work with
existing SOA components.


     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] SOAP
> From: Paul Cohen <[hidden email]>
> Date: Thu, October 15, 2009 3:36 am
> To: [hidden email]
> Hi
> On Thu, Oct 15, 2009 at 8:56 AM, Heiko Gering <[hidden email]> wrote:
> > I'm going to implement a soap-client. I've found goanna as the only library
> > to this subject. Unfortunately goanna isn't consistent in the version 1.0
> > from 2008, rev 604.
> > My questions are:
> > Has anybody todo with SOAP?
> > Which library is it based on?
> > Is goanna still alive, are there a mailing list?
> >
> > Any tip would be welcome.
> Are you forced to used SOAP or do you have influence over the server
> API? I would strongly recommend using a HTTP-based REST API for your
> server's web services instead of SOAP. But that is of course only
> possible if you have control of the server!
> /Paul
> --
> Paul Cohen
> www.seibostudios.se
> mobile: [phone]
> e-mail: [hidden email]

[Ian Joyner-2]

On 15 Oct 2009, at 22:59, <[hidden email]> <[hidden email]> wrote:

> Hello Heiko, Paul et al
>
> I'll second Paul's suggestion, but caution that true RESTful  
> approaches
> impose the burden of intelligence on the client, making them heavier.

In fact the reverse is true. (I hope so, otherwise we have just been  
teaching our 3rd year students exactly the wrong thing!) SOAP is the  
heavy approach, since you are building tailored clients which must  
know about the server API to connect to it. REST is very lightweight -  
to connect to a server, the client needs know nothing about the  
servers API - it is all driven by PUT, POST, GET, DELETE nothing else.

The trick is the knowledge of the API is all put in the HTML, the  
server controls that. If the API changes, the server just amends the  
HTML and the whole world is again in sync. This means no software  
updates necessary for server changes, all very lightweight. This is  
the power of the web and why REST allows it to scale up massively,  
whereas SOAP makes you build everything everywhere.

Thus REST is essentially thin client. To build a system there is a set  
of minimal metadata about that system. The different architectural  
styles are about where this metadata is deployed. SOAP is client  
heavy, REST is client light, the metadata is sent from the server to  
the client when needed. It is automatic - you don't need a bunch of  
programmers manually building this into the system. Thus SOAP is  
statically typed and REST the binding is late and dynamic, but the  
very nature of it ensures the client and server cannot be out of sync.  
The client-server contract is always fulfilled (at least from an  
interface point of view). That might actually seemingly make clients  
more intelligent in that they figure out dynamically what is going on  
(but hey there's lots of HTML and XML parsers out there), but actually  
less intelligent in that they know nothing about any service they want  
to talk to.

Thus I even more second Paul's suggestion. SOAP is really only for in-
house intranets, but maybe that is what Heiko is doing. But then again  
that does not make REST not useful in intranets.

I suggest reading Fielding's dissertation:

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

but to help interpret this maybe some other things:

http://en.wikipedia.org/wiki/Representational_State_Transfer
http://www.prescod.net/rest/rest_vs_soap_overview/

But don't think HTML-based is necessarily REST (or conversely that  
REST is HTTP and HTML):

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
http://roy.gbiv.com/untangled/2008/specialization

There is also a book, but I have not got it yet:

http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260/ref=sr_1_1?ie=UTF8&s=books&qid=1255656264&sr=8-1

I second comments on SOA.

Ian

> The great news is the server side work benefits from the looser  
> coupling
> of course.
> A REST-like approach (aka ResourceFul), takes the same resource-
> oriented
> view, but compromises on REST so that it's a bit more like a schema  
> with
> 4 verbs. A lot of so-called RESTful interfaces are really ResourceFul.
> This approach can also be very effective and makes client work  
> simpler,
> but makes them more tightly coupled with the server. A well designed
> URI schema can minimize issues on that front, so you're not stuck with
> the old RPC lock step problem.
>
> Some might argue that the looser couple of true REST represents a  
> better
> evolutionary model, but a counter argument is that the benefit to the
> species is possible only if it does not compromise an individual's
> viability. Forcing developers to build heavier clients might just tip
> the scales the wrong way.
>
> In any case, it's worthwhile learning and understanding the benefits  
> of
> REST and near-REST approaches.
>
> While on the subject (sorry to hijack your topic Heiko - I'm sure I'll
> hear from someone on this), has anyone done any work with SOA and
> Eiffel. It strikes me as a great match, and SOA even talks about
> contracts (though not quite so formally as DbC). I'd love to see an  
> ESB
> written in Eiffel, for example, and a set of Eiffel APIs to work with
> existing SOA components.
>
> R
>
> ==================================================
> Roger F. Osmond
>
> > -------- Original Message --------
> > Subject: Re: [eiffel_software] SOAP
> > From: Paul Cohen <[hidden email]>
> > Date: Thu, October 15, 2009 3:36 am
> > To: [hidden email]
> > Hi
> > On Thu, Oct 15, 2009 at 8:56 AM, Heiko Gering  
> <[hidden email]> wrote:
> > > I'm going to implement a soap-client. I've found goanna as the  
> only library
> > > to this subject. Unfortunately goanna isn't consistent in the  
> version 1.0
> > > from 2008, rev 604.
> > > My questions are:
> > > Has anybody todo with SOAP?
> > > Which library is it based on?
> > > Is goanna still alive, are there a mailing list?
> > >
> > > Any tip would be welcome.
> > Are you forced to used SOAP or do you have influence over the server
> > API? I would strongly recommend using a HTTP-based REST API for your
> > server's web services instead of SOAP. But that is of course only
> > possible if you have control of the server!
> > /Paul
> > --
> > Paul Cohen
> > www.seibostudios.se
> > mobile: [phone]
> > e-mail: [hidden email]
>
>
>

[Paul Cohen]

HI,

On Fri, Oct 16, 2009 at 3:47 AM, Ian Joyner <[hidden email]> wrote:

> On 15 Oct 2009, at 22:59, <[hidden email]> <[hidden email]> wrote:
> > I'll second Paul's suggestion, but caution that true RESTful
> > approaches
> > impose the burden of intelligence on the client, making them heavier.
>
> In fact the reverse is true. (I hope so, otherwise we have just been
> teaching our 3rd year students exactly the wrong thing!) SOAP is the
> heavy approach, since you are building tailored clients which must
> know about the server API to connect to it. REST is very lightweight -
> to connect to a server, the client needs know nothing about the
> servers API - it is all driven by PUT, POST, GET, DELETE nothing else.

> Thus I even more second Paul's suggestion. SOAP is really only for in-
> house intranets, but maybe that is what Heiko is doing. But then again
> that does not make REST not useful in intranets.

That is exactly what I have been thinking, but not really had any
empirical evidence for; that the "market" for SOAP is in in-house
intranets. I think one reason is that it so, is because in in-house
environments SOAP is seen as the modern replacement of
CORBA/COM/RMI/whatever. In in-house environments, system designers
think of tightly coupled (type) systems and look back at previous
tightly coupled protocols and techniques. So SOAP *seems* the right
way to go.

I think this is wrong and I think the advantages of (HTTP-based) REST
over SOAP are just as strong in in-house systems as for external web
systems. I think many people fail to see that HTTP really is a
full-blown application protocol and not just or simply a transfer
protocol (despite the name)! Furthermore HTTP has great performance
and scales well, as all the existing web applications and services on
Internet prove! It is also ridiculously easy to debug and test REST
services compared to SOAP (or CORBA/COM/etc) services.

I know I might be seen as swearing in church when I say, on an Eiffel
mailing list, that enforcing universal type systems is not good in
large scale distributed systems! ;-) HTTP-based REST interfaces
sacrifice type safety for simplicity and flexibility, and enable (and
encourage) more loosely coupled system integration. This is extremely
desirable when projects or organizations do not have control over BOTH
the server and client side. This is of course the common case on the
Internet and is the premise for developing mash up-oriented system
solutions.

There are so many good arguments for type safety which I don't at all
disagree with; I simply think they don't apply at the system interface
level, like the client/server interface level. At that level the
interface should be more compared to the human/computer interface
typically manifested as graphical user interfaces. No one expects the
type system to be compiled with the users brains; instead we engage
usability and user interface designers to develop good REPRESENTATIONS
of the data and features that humans can understand and easily relate
to. I think the same applies to high level system interfaces. They too
should work with high level resources and representations and basic
operational metaphors; like PUT, POST, GET & DELETE. A well designed
system makes its services and data available in the easiest way
possible and enforces as few technical requirements as possible on
potential future clients; that is what HTTP-based REST interfaces do.

There is a reason for the all the web systems on the Internet not
being recompiled (as a universal type system) every morning! Yet it
works and scales surprisingly well!

> I suggest reading Fielding's dissertation:
>
> http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

For anyone interested in writing business applications for the web it
is highly recommended reading!

> http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260/ref=sr_1_1?ie=UTF8&s=books&qid=1255656264&sr=8-1

That book is indeed a very good summary of the REST principles with
lots of practical examples.

/Paul

--
Paul Cohen
www.seibostudios.se
mobile: [phone]
e-mail: [hidden email]

[rfo]

Hi Paul (et al)

I seem to have lost the intermediate message, but I need to reply to it
anyway, despite the topic being out of scope for this board. My apologie
to the other readers if this is not helpful information.

A true RESTful interface does indeed impose the burden of
__intelligence__ on the client more so than the "ResourceFul" interfaces
that most so-called RESTful interfaces really are.  Using semi-RESTful
models that resemble SNMP with URIs imposes less client burden than true
RESTful because there is more information embedded in the schema (the
structure of information the URIs represent).  When the client has to
work with pretty much nothing but a media type, it has to be more
intelligent.  The protocol interface remains extremely simple, but they
are not the same thing, and that is an important point to consider.

I am not comparing SOAP and REST and would never, ever, ever claim that
REST is heavier than SOAP, and that is not at all what I said.  There is
a huge amount of misunderstanding about genuine REST interfaces and
probably just as much misinformation.  The most common misconception is
that all you need to be RESTful is to use HTTP methods and have a URI
structure.  That is not the case.  One can certainly design such an
interface and it will serve them quite well but it is not REST because
it is not hypermedia-oriented and it requires the client to follow a
deep structure of information, violating 2 key primcipals espoused by
Fielding.

The greater benefit of true RESTful interfaces is that they further
decouple the client from the server by removing the need to be in
lock-step on URI structure.  That's the 'ST' part - state transfer at
work.  The tradeoff is that the client needs to know what to do with
media types and state rather than simply knowing what to do with a fixed
structure of information.  In many cases, that's a good tradeoff and in
some, it's just not worth it.  That is why so many interfaces that claim
to be RESTful are not.  That doesn't mean they're bad, or that they're
SOAP; they're just not truly RESTful according Fielding's definitions.

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] SOAP, REST, and SOA
> From: Paul Cohen <[hidden email]>
> Date: Fri, October 16, 2009 6:16 am
> To: [hidden email]
> HI,
> On Fri, Oct 16, 2009 at 3:47 AM, Ian Joyner <[hidden email]> wrote:
> > On 15 Oct 2009, at 22:59, <[hidden email]> <[hidden email]> wrote:
> > > I'll second Paul's suggestion, but caution that true RESTful
> > > approaches
> > > impose the burden of intelligence on the client, making them heavier.
> >
> > In fact the reverse is true. (I hope so, otherwise we have just been
> > teaching our 3rd year students exactly the wrong thing!) SOAP is the
> > heavy approach, since you are building tailored clients which must
> > know about the server API to connect to it. REST is very lightweight -
> > to connect to a server, the client needs know nothing about the
> > servers API - it is all driven by PUT, POST, GET, DELETE nothing else.
> > Thus I even more second Paul's suggestion. SOAP is really only for in-
> > house intranets, but maybe that is what Heiko is doing. But then again
> > that does not make REST not useful in intranets.

Truncated

[Ian Joyner-2]

Lots to think about in there. Certainly, I don't think you can  
characterize SOAP and REST as either extra- or intra- net. However,  
for suitability of purpose it seems to be dividing that way.

What I'm thinking is that the difference is mainly in the UI. For  
intensive daily users of a service, you probably want a tailored  
(desktop) app. For casual users (who might be many in number) a web/
browser-based system will do. That does not mean that you can't use  
REST to drive the client-server interface in a special purpose app.  
iPhone seems to be doing this with app store apps. People actually  
like this interface.

On CORBA and some comments on SOAP, Michi Henning's ACM Queue article  
is quite insightful:

http://queue.acm.org/detail.cfm?id=1142044

As for typing being inconsistent with dynamic needs of the web, I  
think they are at two different levels like you say. However, where  
you have client/server systems DbC would seem very appropriate.  
Obviously universally type checking the whole web is impractical, but  
I think this aspect of REST could be reconciled with strong typing at  
the correct level.

Ian

On 16 Oct 2009, at 21:16, Paul Cohen wrote:

> HI,
>
> On Fri, Oct 16, 2009 at 3:47 AM, Ian Joyner <[hidden email]> wrote:
> > On 15 Oct 2009, at 22:59, <[hidden email]> <[hidden email]>  
> wrote:
> > > I'll second Paul's suggestion, but caution that true RESTful
> > > approaches
> > > impose the burden of intelligence on the client, making them  
> heavier.
> >
> > In fact the reverse is true. (I hope so, otherwise we have just been
> > teaching our 3rd year students exactly the wrong thing!) SOAP is the
> > heavy approach, since you are building tailored clients which must
> > know about the server API to connect to it. REST is very  
> lightweight -
> > to connect to a server, the client needs know nothing about the
> > servers API - it is all driven by PUT, POST, GET, DELETE nothing  
> else.
>
> > Thus I even more second Paul's suggestion. SOAP is really only for  
> in-
> > house intranets, but maybe that is what Heiko is doing. But then  
> again
> > that does not make REST not useful in intranets.
>
> That is exactly what I have been thinking, but not really had any
> empirical evidence for; that the "market" for SOAP is in in-house
> intranets. I think one reason is that it so, is because in in-house
> environments SOAP is seen as the modern replacement of
> CORBA/COM/RMI/whatever. In in-house environments, system designers
> think of tightly coupled (type) systems and look back at previous
> tightly coupled protocols and techniques. So SOAP *seems* the right
> way to go.
>
> I think this is wrong and I think the advantages of (HTTP-based) REST
> over SOAP are just as strong in in-house systems as for external web
> systems. I think many people fail to see that HTTP really is a
> full-blown application protocol and not just or simply a transfer
> protocol (despite the name)! Furthermore HTTP has great performance
> and scales well, as all the existing web applications and services on
> Internet prove! It is also ridiculously easy to debug and test REST
> services compared to SOAP (or CORBA/COM/etc) services.
>
> I know I might be seen as swearing in church when I say, on an Eiffel
> mailing list, that enforcing universal type systems is not good in
> large scale distributed systems! ;-) HTTP-based REST interfaces
> sacrifice type safety for simplicity and flexibility, and enable (and
> encourage) more loosely coupled system integration. This is extremely
> desirable when projects or organizations do not have control over BOTH
> the server and client side. This is of course the common case on the
> Internet and is the premise for developing mash up-oriented system
> solutions.
>
> There are so many good arguments for type safety which I don't at all
> disagree with; I simply think they don't apply at the system interface
> level, like the client/server interface level. At that level the
> interface should be more compared to the human/computer interface
> typically manifested as graphical user interfaces. No one expects the
> type system to be compiled with the users brains; instead we engage
> usability and user interface designers to develop good REPRESENTATIONS
> of the data and features that humans can understand and easily relate
> to. I think the same applies to high level system interfaces. They too
> should work with high level resources and representations and basic
> operational metaphors; like PUT, POST, GET & DELETE. A well designed
> system makes its services and data available in the easiest way
> possible and enforces as few technical requirements as possible on
> potential future clients; that is what HTTP-based REST interfaces do.
>
> There is a reason for the all the web systems on the Internet not
> being recompiled (as a universal type system) every morning! Yet it
> works and scales surprisingly well!
>
> > I suggest reading Fielding's dissertation:
> >
> > http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
>
> For anyone interested in writing business applications for the web it
> is highly recommended reading!
>
> > http://www.amazon.com/RESTful-Web-Services-Leonard-Richardson/dp/0596529260/ref=sr_1_1?ie=UTF8&s=books&qid=1255656264&sr=8-1
>
> That book is indeed a very good summary of the REST principles with
> lots of practical examples.
>
> /Paul
>
> --
> Paul Cohen
> www.seibostudios.se
> mobile: [phone]
> e-mail: [hidden email]

[Ian Joyner-2]

Hi Roger,

Yes I see what you mean, but since the topic was SOAP, REST, and SOA,  
it seemed natural to assume that the statement REST is heavier meant  
implicitly heavier than SOAP. So you can see why people might have  
read your comment that way, even if that's not what you meant.

I can see your point that a client needs to have the knowledge to  
process whatever type is passed to it. However, that is independent of  
REST and is true for any way you do this. That is, to play a movie,  
you need a movie player on the client, which ever way. Fundamentally,  
I think the amount of knowledge about the system is the same, it just  
depends which way you cut the cake (so you can have your cake and eat  
it).

Absolutely agree that REST is more than just using HTTP and URIs. I  
think they key is to expose nothing, or as little as possible,  
especially the structure of your resource. That means you don't expose  
types, but that small steps are taken at any stage. Things need to be  
changeable. Clients having knowledge of structure and interface are  
thus brittle. I think I am reading that in your last paragraph.

I'm still thinking about this very much, as I think is the rest of the  
industry, so hopefully not too many misundertandings and flame wars  
arise out of that.

Ian

On 16 Oct 2009, at 22:49, <[hidden email]> wrote:

> Hi Paul (et al)
>
> I seem to have lost the intermediate message, but I need to reply to  
> it
> anyway, despite the topic being out of scope for this board. My  
> apologie
> to the other readers if this is not helpful information.
>
> A true RESTful interface does indeed impose the burden of
> __intelligence__ on the client more so than the "ResourceFul"  
> interfaces
> that most so-called RESTful interfaces really are. Using semi-RESTful
> models that resemble SNMP with URIs imposes less client burden than  
> true
> RESTful because there is more information embedded in the schema (the
> structure of information the URIs represent). When the client has to
> work with pretty much nothing but a media type, it has to be more
> intelligent. The protocol interface remains extremely simple, but they
> are not the same thing, and that is an important point to consider.
>
> I am not comparing SOAP and REST and would never, ever, ever claim  
> that
> REST is heavier than SOAP, and that is not at all what I said. There  
> is
> a huge amount of misunderstanding about genuine REST interfaces and
> probably just as much misinformation. The most common misconception is
> that all you need to be RESTful is to use HTTP methods and have a URI
> structure. That is not the case. One can certainly design such an
> interface and it will serve them quite well but it is not REST because
> it is not hypermedia-oriented and it requires the client to follow a
> deep structure of information, violating 2 key primcipals espoused by
> Fielding.
>
> The greater benefit of true RESTful interfaces is that they further
> decouple the client from the server by removing the need to be in
> lock-step on URI structure. That's the 'ST' part - state transfer at
> work. The tradeoff is that the client needs to know what to do with
> media types and state rather than simply knowing what to do with a  
> fixed
> structure of information. In many cases, that's a good tradeoff and in
> some, it's just not worth it. That is why so many interfaces that  
> claim
> to be RESTful are not. That doesn't mean they're bad, or that they're
> SOAP; they're just not truly RESTful according Fielding's definitions.
>
> R
>
> ==================================================
> Roger F. Osmond
>
> > -------- Original Message --------
> > Subject: Re: [eiffel_software] SOAP, REST, and SOA
> > From: Paul Cohen <[hidden email]>
> > Date: Fri, October 16, 2009 6:16 am
> > To: [hidden email]
> > HI,
> > On Fri, Oct 16, 2009 at 3:47 AM, Ian Joyner <[hidden email]>  
> wrote:
> > > On 15 Oct 2009, at 22:59, <[hidden email]>  
> <[hidden email]> wrote:
> > > > I'll second Paul's suggestion, but caution that true RESTful
> > > > approaches
> > > > impose the burden of intelligence on the client, making them  
> heavier.
> > >
> > > In fact the reverse is true. (I hope so, otherwise we have just  
> been
> > > teaching our 3rd year students exactly the wrong thing!) SOAP is  
> the
> > > heavy approach, since you are building tailored clients which must
> > > know about the server API to connect to it. REST is very  
> lightweight -
> > > to connect to a server, the client needs know nothing about the
> > > servers API - it is all driven by PUT, POST, GET, DELETE nothing  
> else.
> > > Thus I even more second Paul's suggestion. SOAP is really only  
> for in-
> > > house intranets, but maybe that is what Heiko is doing. But then  
> again
> > > that does not make REST not useful in intranets.
>
> Truncated
>
>

[rfo]

Hi Ian!

All very well said.  Brittleness is an interesting phenomenon.  Loose
coupling addresses one source of it (a big one albeit), but there are
others.  RPCs used to make me crazy with lock-step on not only structure
of information, but function as well.  A ResourceFul interface (call it
SNMP over HTTP if you wish) retains some of that, but by removing the
procedure calls, eliminates one of the dimensions.  For some apps, it's
probably OK - if the structure of information is sufficiently stabile to
warrant it (in most cases, no such luck).

The extreme current interpretation of loose coupling as the cure-all is
SOA, but despite claims to the contrary, it suffers from the ancient
top-down model of a central supervior knowing everything.  I thought we
left that behind in the 70s.  SOA has many benefits of course but it's
dark underbelly I suspect will be a popular flame war of the future.

I have had the misfortune of seeing so-called RESTful interfaces whose
URIs are actually VERBS. OMG!  Poor Roy :)  He must be twitching
uncontrollably when he sees that sort of thing happening under his
RESTful banner.

     R

==================================================
Roger F. Osmond

> -------- Original Message --------
> Subject: Re: [eiffel_software] SOAP, REST, and SOA
> From: Ian Joyner <[hidden email]>
> Date: Fri, October 16, 2009 8:30 am
> To: [hidden email]
> Hi Roger,
> Yes I see what you mean, but since the topic was SOAP, REST, and SOA,  
> it seemed natural to assume that the statement REST is heavier meant  
> implicitly heavier than SOAP. So you can see why people might have  
> read your comment that way, even if that's not what you meant.
> I can see your point that a client needs to have the knowledge to  
> process whatever type is passed to it. However, that is independent of  
> REST and is true for any way you do this. That is, to play a movie,  
> you need a movie player on the client, which ever way. Fundamentally,  
> I think the amount of knowledge about the system is the same, it just  
> depends which way you cut the cake (so you can have your cake and eat  
> it).
> Absolutely agree that REST is more than just using HTTP and URIs. I  
> think they key is to expose nothing, or as little as possible,  
> especially the structure of your resource. That means you don't expose  
> types, but that small steps are taken at any stage. Things need to be  
> changeable. Clients having knowledge of structure and interface are  
> thus brittle. I think I am reading that in your last paragraph.
> I'm still thinking about this very much, as I think is the rest of the  
> industry, so hopefully not too many misundertandings and flame wars  
> arise out of that.
> Ian

> > Truncated
> >
> >

[Paul Cohen]

Hi,

I'd just like to comment Roger's observation:

On Fri, Oct 16, 2009 at 2:59 PM, <[hidden email]> wrote:
> I have had the misfortune of seeing so-called RESTful interfaces whose
> URIs are actually VERBS. OMG! Poor Roy :) He must be twitching
> uncontrollably when he sees that sort of thing happening under his
> RESTful banner.

Yes, the principles of RESTful interfaces are often
misused/abused/misunderstood in many ways in HTTP-based
implementations. Maybe that could be argued to be one disadvantage of
REST.

The question of what constitutes a system interface and what
properties such an interface should have is really important in the
context of systems integration and the Internet.

/Paul

--
Paul Cohen
www.seibostudios.se
mobile: [phone]
e-mail: [hidden email]