SOA and Service Orientation
SOA Web Services (SOAP is just a piece of the technology stack) and ReST are two architectural constraints that solve the same problem: distributing services over the network.
The main different between the two is that SOA built a completely new technology stack to solve the problem. New specifications such as SOAP, WSDL, and new technology components such as the ESB, the Service Registry, etc… One of the main problems of SOA WS, was that it extensively used XML and sometimes with encrypted envelopes. In the early 00’s, processing large XML payloads with software was just impossible, not to say encrypted payloads that sometimes needed to be decrypted for routing. So you ended up buying dedicated hardware to enable this. On the other hand, you needed to buy a whole new set of software components to get your full SOA vision in place. In general, it was pretty expensive to become a service oriented company. So only large companies implemented SOA and in any case, due to lack of network effects, SOA stayed contained within the firms’ boundaries, hindering the SOA vision of dynamic or programmable value chains across industries.
ReST success in the Web 2.0 era
Besides, ReST used existing technologies that were widely deployed: HTTP for semantics and communications protocol and JSON as representation format. Using JSON allowed using the browser as client because JSON easly maps to Javascript objects. In any case, it is inexpensive to parse in any runtime. Using HTTP meant that you could distribute your service across the internet without any further investment: no need for special proxies or hardware processors.
In my opinion, the great advantage of ReST to its success has been using an existing technology platform: the web, its protocols and formats; for deployment.
Finally, SOA and ReST are architectura approaches where you publish an interface or contract that defines how to interact with a service. What you can do and what you can retrieve from the service can’t be customized by the client. Or better expressed, the client cannot customize how he interacts with the service in terms of the data exchanged to achieve a goal.
GraphQL
GraphQL is a query language specification over the HTTP protocol. Contrary to ReST, in GraphQL all interactions are performed via a single endpoint or URI via HTTP Post method. In GraphQL, you define a schema of the resources your are exposing and the queries and mutations you can perform on those resources. The client can define explicit interest on specific attributes of specific resources to retrieve when querying or mutating (creating or updating resources). Unlike in ReST, queries and mutations can traverse and retrieve or update data from multiple resources with just one call. GraphQL is a great complement to ReST APIs with large object graphs or complex representation structures. It is also great for situations where client performance has obliged the development team to build different API layers for different clients, like mobile clients.
In the near future, GraphQL will complement ReST APIs allowing for customized consumption of services.