CODEWITHSUNDEEP
architecturesoamicroservices
perco
perco

Reputation: 91

SOA - Microservices : Use API REST or SOAP

I'm face to a big dilemm : in my company, we are working on microservices architecture and switching to a full SOA eco system.

Some consultants and developpers say it would be better to SOAP for web services, because it would allow to specify and give a validated format to all developer teams. I'm scared using SOAP we would be restricted at the end.

Based on your experience, for a SOA / Microservices architecture, would it be better to use SOAP or REST API ?

Thanks in advance for your helpful feedback.

Upvotes: 9

Views: 10508

Answers (3)

Koitoer
Koitoer

Reputation: 19543

It's hard to choose an architecture style based on the information you provided in your question, as you don't explain the kinds of business requirements or constraints you have. Also you didn't explain what will be the use of those services.

I have been working with SOAP and REST for a while, I can tell you that both have adv/dis. But, instead of enumerating over those, I will try to give my reasons and scenarios in which I will choose one over the other.

REST

  1. If services will be consumed by a web browser internet application, mobile application (when processing power is 'low') I will choose REST, as the communication is being made in json format which is more friendly with javascript technologies and the processing and parsing time is less than XML.
  2. When services will expose the data as part of a simple API giving access to the user to do CRUD operations, or when not much business logic is involved in the processes. I will choose REST too if I have to build a public API.
  3. If time is in play, implementation of REST is simpler than SOAP. As there are no standards you don't need to have contracts. There are some best practices, but at the end you could use HTTP verbs as you want and create URI style in the way you prefer, but having this much flexibility will make you at some point start doing a kind of RPC API instead of a resource API (remeber REST is more about resources).
  4. Take advantage of cache provide by http GET verb in browsers, if the purpose of your service is expose information on web page app.
  5. From a developer's perspective, which is always important, it is faster to build these kind of services. You just need to know a framework that supports REST, such as JAX-RS, Spring REST, Jersey, and some notions of JSON. The learning curve is also smaller.
  6. It is a lightweight form of transport information, and it is faster as it doesn't require extensive processing.

SOAP

  1. Have contracts that defines the communication within the services, you will be tied to this contract and your clients must follow it too. Any change in this contract will impact all your clients. You must always document what contracts you must use for your operations.
  2. Have interesting standards that can work in the system integration as WS-Interoperability, WS-addressing, WS-security, so basically is a technology that have several standards which makes easier the phase of agreement, not always the implementation.
  3. Can be used with different transport layer smtp, http, if you want to have different kind of clients.
  4. Good standard to transport binary data MTOM/XOP or SwA. If prefer this one to send the bytes in the body of a PUT request.
  5. Better definition of security and integrity, a lot of options comming from the standards, normally the more used in REST is OAuth.
  6. From the developer perspective this will take more time to learn and also you need to have at least very basic knowledge of XSD, XPath, WSDL and other concepts. In some situations following the standards is not always easy. You have good tools and frameworks to build them JAX/WS, Spring-ws, CXF.

Answering your question and thinking in a small/medium company trying to standardize the IT infrastructure, I would choose SOAP as it has more mature tool support in all areas. Personally, I like SOAP:fault messages, the RPC style for business operations that SOAP offers. Assuming that your microservices are not related to a specific field, I think have some kind of ESB could help you in managing the entire infrastructure and set your business rules. On occasion, people may think SOAP is over-engineering the solution. But, I go with the idea as it is a standard that has been in the market for a while.

Upvotes: 11

Danesh
Danesh

Reputation: 1437

With the evolution of standards such as RAML and Swagger to define the REST APIs, the difference between SOAP and REST web services is narrowing. If the focus is on exposing APIs as the earlier answerer mentioned, REST is a better choice as there are plenty of lightweight API management products that support this.

Upvotes: 0

Koen Roevens
Koen Roevens

Reputation: 131

Arguably the biggest benefit of a microservices architecture is the increase in speed with which you can roll out new features into production. In order to achieve that the microservices should be as much as possible independent from each other. WSDL-contracts have the tendency to result in a tighter coupling in comparison with REST-contracts. From this perspective it makes a lot of sense to opt for REST. But it all depends on the goals that you did want to accomplish when you decided to go for a microservices or a SOA architecture.

Upvotes: 3

Related Questions