REST vs. WS-*, a Parable

Discussions

News: REST vs. WS-*, a Parable

  1. REST vs. WS-*, a Parable (37 messages)

    Elliotte Rusty Harold has written "REST vs. WS-*: a Parable," discussing the differences in approach between REST and - for lack of a better term - traditional Web services, represented by the multitude of W3C specifications. In it, he uses a protagonist who represents REST, as the simple, can-do protocol, and sees WS-* as being overcomplicated and requiring endless maintenance.
    Hi there. My name’s Rusty, and I’m an air conditioning tech. I’m not a rocket scientist, but I know how to wield an electronic screwdriver and recharge the freon in a unit. Lately I’ve taken a job with Roy’s Environmental Systems Technology. It sounds impressive, but really it’s just another air conditioning and heating company, nothing cutting edge, nothing fancy. We mostly just call it REST.

    Lately, however, we’ve been losing business to a newcomer in town, and I’m not quite sure why. A couple of years ago Water Supply-Strategic Tactical Air Recycling (WS-STAR) opened up a branch in our town. WS-* (as my IM crazy kids would type) came about from the merger of Secure Operations Air and Power (SOAP) with Expert Machine Lubrication: Radiators, Power, and Cooling (XML-RPC).
    Highly enjoyable reading, and worth some thought when one is considering WS-* against REST - although it should be added that sometimes, you really do want the full WS-* stack, despite its potential complexity.

    Threaded Messages (37)

  2. REST vs. WS-*, a Parable[ Go to top ]

    WS-* presumes SOAP and involves providing many declarative services to an internet messaging environment. I would be interested in seeing scenarios where these things are also accomplished using REST (e.g. transactions, security, policy, etc.)
  3. REST vs. WS-*, a Parable[ Go to top ]

    WS-* presumes SOAP and involves providing many declarative services to an internet messaging environment. I would be interested in seeing scenarios where these things are also accomplished using REST (e.g. transactions, security, policy, etc.)

    It would also be interesting to see those REST scenarios where the implementations are even remotely interoperable with other implementations.
  4. REST vs. WS-*, a Parable[ Go to top ]

    Exactly. There are no standards for doing these things (represented by the plethora of WS-* standards) in REST, so if the need does arise, what do you do?

    SOAP document/literal is very simple so the difference between doing that and schema defined REST is minor, but when you need to add additional functionality, SOAP's extensibility is there to help you. (BTW, WSDL is not required for SOAP so don't whine about that. WSDL is a nice thing to have for what it does.)

    For example, WS-Security lets me do SAML in a transport independent way - over MoM, over HTTP, over sockets, SMTP, etc. WS-* standards, such as WS-ReliableMessaging, are not there for me to use directly but for my vendors to use with each other to achieve inter-operability. I could use it directly, but I'd rather let my MoM/ESB vendor deal with it. In fact, most if not all of what goes into a SOAP header (which is itself optional) is really intended to be dealt with by your middleware vendors, not the application programmers. At least that is where it is supposed to be heading.

    Personally I think the whole WS-* bit has gone way too far, but then that's because a lot of what I see as unnecessary is what I don't need on the edges. Nevertheless, the existance of an unnecessary (to me) WS-* standard really doesn't affect me because I don't have to use it.

    The point is that if you compare what it takes to accomplish the exact same things in SOAP versus another XML messaging scheme, SOAP is never much harder and is often (when complex things and interoperability are in play) much easier to use.
  5. .... WSDL is a nice thing to have for what it does...
    Not everybody agreed, and I am among them, please look at the thread:
     "WSDL tools an abomination" http://www.theserverside.com/news/thread.tss?thread_id=37238
  6. Reading the above replies I started doubting where I lived. On the Moon? Oh no, not at all. Looking around, I'm still here on the lovely Earth ;)

    There were so many 'if's and 'in the future', and so on, that those guys need to be brought back to this reality.
  7. Reading the above replies I started doubting where I lived. On the Moon? Oh no, not at all. Looking around, I'm still here on the lovely Earth ;)There were so many 'if's and 'in the future', and so on, that those guys need to be brought back to this reality.

    Exactly!

    Or rather - 'I have a 100 kg hammer, now I need to find me a nail'.

    This collective mass hypnosis with SOAP-SOA-ESB reminds me of EJBs mania five years ago except that this one is just worst.
  8. If you read the article you will see that its not WSDL that the post criticizes, its the tooling. The tooling is pretty bad I agree. And that is a problem if you are trying to harness the power of WSDL, but the problem is not WSDL itself.

    WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it. It allows me to harness the capabilities of ESBs, services management products, governance products, etc. There is no good substitute in for a large enterprise trying to integrate with SOA.
  9. WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it.
    So does IDL, ODL,and even COBOLs copybook!
    WSDL is unnecessary overcomplicated which is obvious when we look at that ISBN WSDL example. Please read the thread too, not just the article.
     It allows me to harness the capabilities of ESBs, services management products, governance products, etc.
    I would say it is supposed to ....
    There is no good substitute in for a large enterprise trying to integrate with SOA.
    What does it mean for Pete's sake?! O the power of brainwashing!
    There is no SOA product, standard, etc. that is called SOA. SOA is the newest marketing term to label what people
    were doing when tried to integrate systems into something bigger. SOA simply put is just a mindset. Ans services not NOT have to be XML based. It is better for them not to be IMO.
  10. REST vs. WS-*, a Parable[ Go to top ]

    If you read the article you will see that its not WSDL that the post criticizes, its the tooling. The tooling is pretty bad I agree. And that is a problem if you are trying to harness the power of WSDL, but the problem is not WSDL itself. WSDL allows me to define service interfaces in an implementation independent way and define multiple transports and protocols for accessing it. It allows me to harness the capabilities of ESBs, services management products, governance products, etc. There is no good substitute in for a large enterprise trying to integrate with SOA.
    Oh yes,
    there is a huge problem with WSDL itself !!!
    Take a look at a much more precise and better analysis made by Michi Henning at www.zeroc.com

    In short, what I find rather "uncomfortable" is exactly the specification of the endpoints in WSDL.
    It is totally crazy.
    What if I have an identical service (in terms of operations) provided by multiple independent providers ?
    Is UDDI the answer ?
    Really I need that monster to reference 2 endpoints (think about testing enviroment) ?
    OK, I am oldie, but I prefer CORBA style, with IDL containing only the interface definitions and simple
    string parsing for endpoint identification.

    Guido
  11. REST vs. WS-*, a Parable[ Go to top ]

    Take a look at a much more precise and better analysis made by Michi Henning at www.zeroc.com

    Where exactly is the article in zeroc's page?
  12. Take a look at a much more precise and better analysis made by Michi Henning at www.zeroc.com
    Where exactly is the article in zeroc's page?
    I think he meant this:
    http://www.zeroc.com/iceVsSoap.html

    Zeroc folks are VERY smart and only people who actually come up with a way to really improve CORBA. Please see another excellent article at their site:
    http://www.zeroc.com/iceVsCorba.html
  13. I worked extensively with CORBA in the past and I'm sure he (ICE) has some valid points here but one that I firmly disagree with is:

    "SOAP is a very basic protocol, with no support for object-oriented development of distributed applications."

    Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
  14. "Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.

    There are two camps,
    one says: you do not need this because you should not be doing this;
    and the second says: there is the platform that does all you might need in this particular domain;
    SOAP and M$ ideology are vivid examples on the camp one, and Unix and CORBA clearly belong to the camp two.

    Answering your question: because for certain scenarios it is the best thing to do. Speaking from personal experience: at the end of last century I was involved in the CORBA project and we have started with basic things, but when our demand grew we just discovered that CORBA has already thought about that and there is implementation. That was very cool and enjoyable experience.

    Not so with any of the SOAP and XML projects I was involved or observed: as the demand grew it lead to the Oh s-it! moments when team realized that a need to amend those crippled XML based solution with something custom, reinvent the wheel basically. Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis.
  15. ...Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis.
    Clap, clap
    +1


    Guido.
  16. REST vs. WS-*, a Parable[ Go to top ]

    ...Lets face it: the whole SOAP opera is about reinventing CORBA infrastructure and services on the XML basis.
    Clap, clap+1Guido.

    SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.
  17. Re: REST vs. WS-*, a Parable[ Go to top ]

    SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.
    Actually, XML is not very heavy in itself. But add meta-data in the requests and responses, references to external files (XML Schema) etc. and you've got one big bloated monster :-)
  18. Re: REST vs. WS-*, a Parable[ Go to top ]

    SOAP, in large part, is nothing but a marketing gimmic. Who wants to hear about CORBA/ICE when you have servers to sell; think of MS, IBM, SUN, HP... They all want to sell you servers and applications that do XML. XML is big, fat, and slow. Bingo, you need hordes of servers just to do simple XML (de)serialization.

    Actually, XML is not very heavy in itself. But add meta-data in the requests and responses, references to external files (XML Schema) etc. and you've got one big bloated monster :-)
    I agree SOAP is terrible. But if SOAP is so bad why has Sun (or should I say the JCP?) adopted it? Paul.
  19. I agree SOAP is terrible. But if SOAP is so bad why has Sun (or should I say the JCP?) adopted it?

    Paul.
    Well, lets see... Who is in the JCP? - Software Vendors And how do they make money? - Selling Software and consulting services and computers. Do they have interest in supporting something that will just work? ...... Your guess?
  20. REST vs. WS-*, a Parable[ Go to top ]

    I worked extensively with CORBA in the past and I'm sure he (ICE) has some valid points here but one that I firmly disagree with is: "SOAP is a very basic protocol, with no support for object-oriented development of distributed applications."Why do we want to use OO to develop distribution? Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
    Why do you disagree ?
    That sentence is plain true.
    An it not in contrast with your point.
    Not all the distributed applications, or not all pieces, can be built as you say.
    More, I don't think OO introduces tightly coupling per se, nor SOA is always loosely coopling.
    I don't see how OO inheritance implies tightly coupling: if an objetc is-a something, thne IS that something, you like or not.
    There is no mandatory relationship mechanism in OO approach.
    It's a matter of design.

    Guido
  21. Re: REST vs. WS-*, a Parable[ Go to top ]

    Developing services themselves using OO makes sense but the integration should be based on Orchestration in any SOA whether web services are used or not. OO just introduces tight coupling via its inheritance and relationship mechnanisms.
    Don't confuse OO and inheritance. This is a common misconception. Classes and Inheritence is just one way to define object implementation, some OO languages do not have classes at all (e.g. the Self language and JavaScript) and dynamic OO languages like Smalltalk have the good sense not to couple objects through explicit declarations of Type (Class) every where. OO is about reducing coupling and increasing cohesion (effective chunking), the thing OO brings to the table is encapsulation (I do not need to know your state to use your service). Dynamic OO is the ultimate loosely coupled, message based SOA. The problem is that so called OO languages derived from C++ (Java and C#) just aren't implemented that way. Paul.
  22. ...(effective chunking)...
    Don't you mean (selective clunking)?
  23. Re: REST vs. WS-*, a Parable[ Go to top ]

    OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems. Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
  24. Re: REST vs. WS-*, a Parable[ Go to top ]

    OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems.
    ????? OO is this ? OK, tonight I will read Rumbaugh again, but I don't think I will find your answers.
    Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
    As I said before, is a matter of design of your distributed object system. Object-orientation does not enforce any of your concerns. I really don't see how inheritance can cause you troubles. If an element of the domain (i.e. an object), has some commonalities with other elements of the domains you have candidates for superclasses from which you can specialize your leaf services. It's a matter of life, things (objects) ARE, you like or not. Guido.
  25. Re: REST vs. WS-*, a Parable[ Go to top ]

    OO is about relationships and abstractions be they inheritance, association, composition or aggregation. They all introduce dependencies that are undesirable in distributed systems. Orchestrators represent flow charts (with some additional longer running "task" support), and they are completely agnostic to the services they are orchestrating. So there are no relationships between services, they are completely decoupled. As I said before, an OO approach can be used to develop the services and even the underlying framework of the orchestration mechnanism but a different type of analysis is required for the SOA itself.
    Hi, I Agree with your view on coupling, but whos definition of OO are you using? Sun have been responsible for more than one OO language. Take a look at this one: http://research.sun.com/self/language.html No classes, no inheritance, no static type coupling, just messaging and object encapsulation. C++ and it's offspring have given OO a bad name. I'm just trying to set the record straight. There is so much mis-communication in our industry (read marketing), that many good ideas been consigned to history or have been re-inveted in a weaker form. Pure message based OO offers everything you can get from SOA and a lot more. Paul.
  26. REST vs. WS-*, a Parable[ Go to top ]

    The SOAP way is not an easy way. Yes, you can develop web services without a WSDL just like you can write code without commenting it. And anyone who has to consume your WSDL-less service now has to write a ton of code by hand because you were too lazy. But, hey, SOAP is easy right? I know, your one of those sick types that have no problem sitting behind a computer and typing all day 24-7 so writing a few thousand lines of code is fun to you. Screw that. REST is easy like Sunday morning, so why waste the time with the WS-* mess.
  27. REST vs. WS-*, a Parable[ Go to top ]

    The SOAP way is not an easy way. Yes, you can develop web services without a WSDL just like you can write code without commenting it. And anyone who has to consume your WSDL-less service now has to write a ton of code by hand because you were too lazy. But, hey, SOAP is easy right? I know, your one of those sick types that have no problem sitting behind a computer and typing all day 24-7 so writing a few thousand lines of code is fun to you. Screw that. REST is easy like Sunday morning, so why waste the time with the WS-* mess.

    Well like I said, you use what you need. Tell me, what is the REST alternative to WSDL (which is not part of SOAP and can describe REST services too)? If you need it or the equivalent for SOAP, you need it for REST. What is the REST equivalent of WS-Security, WS-Addressing, WS-ReliableMessaging, etc., etc.? If you need their functionality for SOAP you would also need it for REST. Your business requirements (security, routing, guaranteed delivery) don't change because of the style you choose.

    Remember I'm talking about SOAP document/literal. That's the same plain XML data you might use in REST wrapped in an <body/> wrapped in and <envelope/>. No RPC/encoded, just a plain XML message. So, how do you accomplish all these things in REST? And if you have a solution that doesn't involve a lot of extra coding, how inter-operable is it?
  28. REST alternative to WSDL[ Go to top ]

    Tell me, what is the REST alternative to WSDL (which is not part of SOAP and can describe REST services too)?
    There are several propositions including:<br/>
    Web Resource Description Language (WRDL)<br/>
    Web Application Description Language (WADL)<br/>
    Simple Message Exchange Descriptor (SMEX-D)<br/>
    And also a standardization discussion at the W3C.
    What is the REST equivalent of WS-Security
    HTTP authentication and SSL.
    WS-Addressing
    The HTTP referrer header works well, additional URI can be provided in the URI (wsa:messageID), in the message or in the URI parameters (wsa:from URI, wsa:to URI) if really needed. Not sure what is the actual business need here.
    WS-ReliableMessaging
    Similar patterns are available. Most of the time you want to be sure that your message arrived. In REST you can simply start a "transaction" which is identified by a unique URI, then use this URI to post your message. This returns an HTTP success status if the request completed with no problem. If the communication was lost before getting this status, you can simply get the status of the transaction by getting the transaction representation at the unique URI. If it actually failed, you can abort/start a new one.

    Regards,
    Jerome Louvel
    Restlet, a REST framework for Java
  29. REST alternative to WSDL[ Go to top ]

    also you might want to have a look at this:
    http://xins.sourceforge.net/
  30. REST alternative to WSDL[ Go to top ]

    also you might want to have a look at this:http://xins.sourceforge.net/
    Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL? How is it a "REST alternative to WSDL"? Please explain. In your explanation please address how this tool deals with

    Non-Java endpoints
    Multiple transports for accessing a Service operation
    Message formats
    Multiple service access protocols - not just SOAP

    - All without using WSDL. Please tell me how. I don't see anything out there that substitutes for WSDL.
  31. REST alternative to WSDL[ Go to top ]

    Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL? How is it a "REST alternative to WSDL"? Please explain. In your explanation please address how this tool deals with

    Non-Java endpoints
    Multiple transports for accessing a Service operation
    Message formatsMultiple service access protocols - not just SOAP- All without using WSDL. Please tell me how. I don't see anything out there that substitutes for WSDL.

    i am not involved with the project so maybe the stuff below is not 100% correct.

    It gives you the choice - that is the nice feature.

    The services are defined in a proprietary -but simple- xml format. Yes - as you said - it includes tools to generate WSDL file from this format (also the api classes, tests etc.).

    You can then access the same service either via REST, XML-RPC or SOAP. The transport is limited to HTTP(S) though.

    also you might even see the definition format of xins as a simple (i am not saying the it gives you the full feature set that all WS-* specs offer) replacement for WSDL - the code generators are xslt templates. So just write a template for your favorite programming language and you have the client api - which you then can distribute to whatever clients you have. OR let the client generate whatever they want from the wsdl.

    But something else:
    There is also another nice feature of REST which hasn't been mention yet. Again only applies for certain use cases though. REST is cacheable by any standard HTTP cache (mod_cache, squid etc. pp).

    One more note on security:
    if you really need very tide security of your service i still prefer to that in the networking layer (vpn,ip restrictions etc).

    Eike
  32. Rather than being an alternative to WSDL, isn't XINS just a tool which (among other things) can generate a WSDL?
    It is a framework for distributed applications. Like each framework it has some constraints:
    - HTTP-based communication
    - RPC-style server-side implementations
    - Java-based server-side implementations

    It combines the following (from http://en.wikipedia.org/wiki/XINS ):
    1. An XML-based specification format (called POX-IDL)
    2. A POX-style RPC protocol (called POX-RPC)
    3. Tool for generating human-readable documentation, WSDL, stubs, WAR files, etc.
    4. A Log4J-based technology for logging (called Logdoc), offering a specification format, internationalization of log messages, generation of HTML documentation and generation of code.
    5. A Java client library for POX-RPC.
    6. A server-side container for Java-based XINS API implementations

    For some more background, read this PDF:
    http://xins.sourceforge.net/frameworks_and_xins.pdf
    Non-Java endpoints
    Multiple transports for accessing a Service operation
    Message formats
    Multiple service access protocols - not just SOAP
    Although POX-RPC is XINS-specific, XINS supports various other protocols, including SOAP and XML-RPC. Also, XINS allows the addition of new protocols. This requires the implementation of a subclass of class CustomCallingConvention.

    So interoperability for clients is not an issue. It can even be called from browsers. Try this test form:
    http://xins.sf.net/demo/specdocs/myproject/MyFunction-testform.html
    All without using WSDL. Please tell me how.
    Indeed, all without WSDL. Instead, it uses a very simple format we call POX-IDL. The problem with it is that it's contained within the XINS project and it's not documented independently. But we are considering splitting XINS in several separate components, because some of them have a use on their own, such as Logdoc:
    http://xins.sourceforge.net/logdoc/1.4.0/server/index.html

    Lastly, here's one of the DTDs for POX-IDL:
    http://xins.sourceforge.net/dtd/function_1_4.dtd

    Have a look at the XINS Primer if you want some more examples.
  33. REST alternative to WSDL[ Go to top ]

    Thanks for this response, Jerome. It's really nice to see some specific information given as to how REST could subsume WS-*. But I see the following issues:

    1.) These alternatives to WSDL either look very similar to WSDL since you have to descripe the method signature somehow or look extremely incomplete (like someone's blog entry).

    2.) Using HTTP auth and SSL for security won't fly in a true internet environment especially in the case of service composition.

    3.) The business need of WS-Addressing is usually coming from the other specifications that utilize it, e.g. it serves as plumbing for WS-Transactions and other specs. However, I have encountered businesses who want to use it for say versioning of services. I don't see how your solution would support this.

    4.) Suppose we have a scenario of a web server forwarding requests to an application server which invokes web services. The RM approach you describe would return success even if the application server were down and the message never reached the actual web service.

    I would predict that since these core WS-* specs are being codified that we will see vast improvement in tooling since vendors don't usually commit much effort to areas that are still in flux.
  34. REST alternative to WSDL[ Go to top ]

    HTTP and SSL - WS-Security is not for encryption, but I can use SAML with HTTP. Unfortunately SAML represents only a subset of what WS-Security does. Its not a substitute.

    As an alternative to WS-ReliableMessaging you say that there are "patterns available". That is all fine and good, but there are patterns available or alternate solutions to any standard you can name. The problem is that these alternatives are not formal standards. In which case you are basically saying that if I use REST services and need the kind of functionality supported by the WS-* stacks that I will need to negotiate standards with every client I deal with. I think the idea of having standards was to avoid that situation because its the very costly hell we are trying to get out of.
  35. REST is a model. WS-* is a standard for communication over a transport. Can WS-* fit the REST architecture model? I would say it can.

    Looking at Flickr, which uses the REST model, I'd say that they've simplified the interface to their underlying repository. How difficult is it to consume there service using Java? From my vantage point, you have to hand code each request and parse each response which is tedious IMO. If they provided a XSD for their document types, I could leverage a tool like XMLBeans or JAXB and get on to coding the requests. If they could provide a WSDL (which they can't because of the way REST urls differ with the way WebService endpoints are modeled...not a good or bad thing...just different) then I could use WSDL to Java tool to create my client API. If they used SAML for security assertions, I could an existing library, like WSS4J, to help manage security in my application. Flickr doesn't do this but that's they're choice and to there credit it is rare you find an enterprise developer with their tools in hand (all open source btw) that wants to interface with a consumer service.

    So REST vs. WS-* isn't the issue. It's about choosing standards to communicate and picking a model that works. Can REST and WS-* coexist...absolutely. Do we need to divide developers on a non issue...no.

    -Noah
  36. So REST vs. WS-* isn't the issue. It's about choosing standards to communicate and picking a model that works. Can REST and WS-* coexist...absolutely. Do we need to divide developers on a non issue...no.-Noah

    Well it is an issue because there is no standard for using WS-* in REST. There is no standard payload format for REST. As you say, its a style. Without some standards you don't have a vendor independent, interoperable way to use WS-*. SOAP provides a place to put the WS-* data and a model for processing it. Technically you could use a SOAP payload in a REST style, but I don't think that is what most people have in mind when they draw the distinction.
  37. The EJB of XML[ Go to top ]

    SOAP -- the EJB of XML. Give up the ghost.
  38. REST vs. WS-*, a Parable[ Go to top ]

    Read the parable and it was light hearted and fun. Faced with WS-* who wouldn't crave for something much simpler? I did, but after reading Roy fieldings paper and asking pertinent questions on the REST discussion group, I concluded that for the type of things I want to do REST just isn't it.

    I got the same feeling as the guy whose post said he needed to check that he was on earth. Most of the posts in this thread I just don't recognise. Doing REST with Soap How? What ever happened to the uniform connector constraint?

    REST does exactly what it says on the box: REpresentational State Transfer - moving mostly static data around using a uniform connector (HTTP GET, PUT, POST etc).

    So what happens when you want to do transactions? Well there's no COMMIT, and no ROLLBACK. As for Objects well forget encapsulation, and behaviour other than GET, PUT etc.

    So what is this discussion all about? Has the level of debate on TSS come to this?

    Paul.