We want to allow our enterprise of service providers to deploy REST or SOAP solutions. These services will become candidates as an "authoritative" service endpoint for a specific request made by a consumer to an enterprise broker. Therefore, we want a mechanism to create a SOAP based interface for exposure by the broker when a provider publishes his REST service to the broker. Any references on how to approach this in a normalized fashion?
views:
96answers:
3The nice thing about REST is that the interfaces are pretty much always the same. You could probably define a SOAP interface that generalizes the CRUD operations of the REST service in a reusable way.
However, I'm not sure why you'd want to encapsulate a REST service in a SOAP layer. The clients of the service would probably find the original REST service just as easy to use as the automatically generated SOAP interface, if not more so.
There's a REST equivalent to WSDL called WADL. You could explore an approach where a REST service provider sends you a description of their API in WADL, you translate the WADL to WSDL, and from the WSDL generate the SOAP APIs your broker offers. Your WADL to WSDL translation simulataneously generates the mapping logic used by your broker to translate each SOAP request to an underlying REST request on the service provider. Offhand I don't know how easy this mapping would be.
However, David Chappell points out that:
Exposing services RESTfully is a better choice in a majority of situations, especially over the Internet. SOAP and the WS-* technologies still have some role, however, particularly inside enterprises.
Each service provider makes the engineering decision to support REST, or SOAP, or both. If a service provider determined that REST-only was the appropriate choice for their web service, then why would adding an intermediary that maps it into the less appropriate choice offer any value? Aren't you just adding a layer of complexity and inefficiency?