The reason is, SOAP related Specs and Standards for WSDL, Attachments and Security are all well established and are currently supported by all major vendors like Microsoft, IBM and Oracle. SOAP allows for better inter-operatbility between Java and .NET the 2 most widely used enterprise stacks. The client in my case was a .NET shop.
On the other hand I would have used REST if I needed to support PHP or Ruby clients. These programming languages have only basic support SOAP, and for those REST is the way to go.
The best practice here is to build your web services in a protocol independent manner. Keep a layer to send receive SOAP or REST request/response messages at the front gate and keep all your business logic behind this layer.
Your SOAP or REST gateway must simply pass parameters to the business logic layer and receive marshallable objects back from it.
Your business logic, must be protocol independent and must be testable without needing a web service container.
One thing for sure. If my web service finds takers, then I will have to support both REST and SOAP over time, There's no way one protocol will serve all my clients.
On the other hand I would have used REST if I needed to support PHP or Ruby clients. These programming languages have only basic support SOAP, and for those REST is the way to go.
The best practice here is to build your web services in a protocol independent manner. Keep a layer to send receive SOAP or REST request/response messages at the front gate and keep all your business logic behind this layer.
Your SOAP or REST gateway must simply pass parameters to the business logic layer and receive marshallable objects back from it.
Your business logic, must be protocol independent and must be testable without needing a web service container.
One thing for sure. If my web service finds takers, then I will have to support both REST and SOAP over time, There's no way one protocol will serve all my clients.
Comments
Post a Comment