REST vs SOAP vs Microservices
REST vs SOAP vs Microservices
SOAP: Simple object access protocol. It has a more rigid set of messaging patterns than REST. Relies exclusive on XML. SOAP need not necessarily be transmitted over HTTP, we can use other protocols such as SMTP etc.
REST: Representational state transfer uses URL and HTTP verbs such as GET, PUT, POST and DELETE to perform actions. Data is in JSON, CSV or RSS format.
Soap Vs Rest
SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:
- Language, platform, and transport independent (REST requires use of HTTP)
- Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
- Standardized
- Provides significant pre-build extensibility in the form of the WS* standards
- Built-in error handling
- Automation when used with certain language products
REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:
- No expensive tools require to interact with the Web service
- Smaller learning curve
- Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
- Fast (no extensive processing required)
- Closer to other Web technologies in design philosophy
Microservices: is more about architecture and REST is more about exposing these microservices. They are easy to understand / modify (because they are small), is the only place having logics/business rule, does not expose any implementation details such as database to ensure loosely coupling; it also implies that the RESTful APIs or Functions that implement Aggregates within a bounded-context should belong to one Microservice because they are tightly coupled in terms of sharing lots of same high level design and architecture, i.e. programming language and frameworks, database access framework, etc. to reduce the complexity as you may not want to maintain a module or bounded context (i.e.Messaging service) that uses different technologies and tech stacks, can be deployed separately without affecting others as long as the interfaces stay same, a few more benefits (such as scale separately, choice of programming languages, etc.), and a few drawbacks as well, for instances, network timeouts (one of the disadvantages in building distributed systems).
Microservices hence is language agnostic, and is loosely coupled. Microservices and REST services solve two different problems, but can thrive together.
