It's gratifying to be in the business long enough to see new paradigms transition from lofty visions to everyday standards. Such is the case with web services. When I first started writing a column for DBTA, the evolution of web services was well underway, although a battle for dominance between competing standards was incomplete. In particular, there was competition between a set of committee-defined standards (WS-this and WS-that) and a looser set of techniques based around simple protocols.
As is so often the case in the software industry, developers continued to program while the standards bodies deliberated. By and large, programmers rejected standards-based mechanisms in favor of a far more flexible approach: implementing web services by transmitting XML documents across HTTP. Programmers discovered that they could use HTTP directives and URL constructs to eliminate a lot of the complexity required by SOAP and its cousins.
Eventually a widespread standard emerged for this simplistic approach: REST (Representational State Transfer).
Strictly speaking, REST is an architectural style, not a platform. To be “RESTful” an API must adhere to several core principles first articulated by Roy Fielding. These principles define how a web application navigates through network of web pages or web resources. REST defines how requests identify resources and navigate to related resources. For instance, a REST request might first identify a specific customer account, then use the results from that request to create a request that navigates to that customers profile.
REST gained popularity throughout the 2000s and today REST using HTTP and JSON has created an almost universal language for Web APIs. In so doing, REST has done more than any other technology to bring the vision of web services to reality. However, similar to all practical general-purpose technologies, REST is not perfectly suited to all scenarios and there have been ongoing attempts to design a “better than REST” platform for web services.
GraphQL has emerged as the favorite alternative to REST for modern web API design. GraphQL was first used internally at Facebook before being open sourced in 2015. GraphQL is described as a data query and manipulation language which at first glance might suggest more in common with SQL than with REST. However, in reality both GraphQL and REST are applicable across a very similar range of web API scenarios.
GraphQL implements a friendlier syntax than REST and provides significant efficiency gains. REST calls typically return all data related to a resource, while a GraphQL query can request subsets of data, reducing network overhead.
GraphQL also allows a request to return related data without having to create specialized API endpoints. For instance, a GraphQL request could request details of a customer and all of that customers’ orders, implicitly navigating the relationships between those entities in the server. In REST, such a request would have to be anticipated and explicitly created or would have to be resolved using multiple REST calls.
GraphQL also provides a strongly typed schema which allows clients to navigate the API endpoints more effectively. This allows for adhoc requests and intelligent API browsers. GraphQL is unlikely to completely overturn REST but appears to take web services one further step forward toward maturity. GraphQL is likely to further expedite the transition from monolithic applications to loosely coupled microservices.
The transition to microservices is generally regarded as a good thing. However, there is a risk that tomorrow’s unmaintainable applications will be a confusing mess of poorly defined microservices. We’ll need strong, self-describing protocols to avoid this scenario and GraphQL seems a step in the right direction.