“webMethods Integration Server 8.2 includes a number of facilities for building and exposing services and data using the REST architectural style. Integration Server now supports all four HTTP methods (GET, PUT, POST, DELETE), as well as REST-style URLs, where resource IDs are embedded in the main URL path. Additionally, content type negotiation is much more flexible, allowing full control over the content type of responses.”
This is focused on IS as the host of interfaces supporting REST principles. A step in the right direction.
As for calling interfaces that adhere to REST principles, I don’t think much has changed.
[Side notes]
There are more than 4 HTTP methods.
REST != HTTP – implementers should keep in mind that a RESTful interface isn’t necessarily always based on HTTP
The reverse invoke (now called gateway) server is used for outside calls coming in to your installation. It is not used when your IS makes calls to outside servers.
I thought one of the benefits of REST was to leverage the built-in verbs of HTTP (POST, GET, PUT, etc.) to implement your service’s actions on a resource or object? The parameterized URL plus an completely optional XML payload provides the interface. You don’t need a SOAP interface on top of all that.
If you need strong type checking, to define your own verbs or action, always need to send or receive an XML message that conforms to a pre-defined schema, need support for multiple protocols (HTTP, JMS or even SMTP) or need maximum interoperability from a variety of clients, then use SOAP.
If the verbs that make up HTTP are sufficient for your application, you’ve spent time understanding how to define an effective RESTful service and you don’t need to exchange more complex XML documents, then REST may be just the ticket.
There are numerous SOAP vs REST comparisons around, some even rise above the flame war level to be pretty useful.
However, REST over SOAP would seem to offer the worst of both worlds.