Beyond REST: Presumptive Architecture, Binary Protocols, and Asynch APIs
Beyond REST: Presumptive Architecture, Binary Protocols, and Asynch APIs
A collection of resources and explanations of several concepts common to architecture and enterprise integration.
Join the DZone community and get the full member experience.Join For Free
Writing API’s in a RESTful style where the Client Server communication happens over HTTP/HTTPS with the HTTP verbs (GET, POST, PUT, DELETE, etc.) to retrieve and send data to remote servers is now extremely popular.
REST is an architectural style for distributed hypermedia systems. Here are the set of constraints that compose the REST style as specified by Roy Fielding in his thesis:
- Client-Server: Separation of concerns
- Client/Stateless-Server: Visibility, scalability
- Caching: Performance improvements
- Uniform Interface: Consistent interactions and better visibility of interactions. Ease of adoption.
- Layered System: Simplified components and improved scalability.
- Code-On-Demand: Allows extensibility.
It is interesting to note the definition Presumptive Architecture, and how using REST techniques for building APIs have become the norm.
"A presumptive architecture is a software architecture (or a family of architectures) that is dominant in a particular domain. Rather than justifying their choice to use it, developers in that domain may have to justify a choice that differs from their presumptive architecture. Non-curious developers may not even seriously consider other architectures, or have the apprehension that all software should conform to the presumptive architecture." Refer: Presumptive Architecture
REST has some huge benefits and there are right reasons for its popularity. Some of the obvious benefits include:
- Uniform interface
- Statelessness and scalability
- Ease of testing
However, there are some shortcomings in REST that are often over looked:
- REST is a style and not a standard. There are frequent opinionated debates going around what is REST and what is not REST. There is a model of RESTful maturity proposed by Leonard Richardson. However the original proponent of REST, Roy Fielding strongly advocates that REST APIs must be hyper text driven. There are new standards for building APIs in REST emerging like ODATA from OASIS that are emerging but are yet to gain much traction.
- The user interfaces are most focused on providing the optimal user experience including reducing multiple round trips between the client and server to render views. REST is more focused on the resource model and could result in a sub optimal experience for the user interfaces.
- Versioning is not consistent on REST and usually results in complications.
- The application-level and transport-level status codes are combined to render the response codes, which some feel to be less optimal (e.g. 304 Not Modified and 400 Bad Request).
- REST API does not offer a rich standardized query interface.
- For data-heavy API, lot of cycles and bandwidth is wasted just for converting ASCII to Binary and vice versa by using REST with ASCII content like XML or JSON.
- High parsing over heads and language specific code need to be written both on Client and Server side.
The industry has seen lot of different integration technologies that have been popular at different point of time:
- Java RMI
- XML RPC
Almost all of them have seen their sunset and it is pretty naive to expect REST to remain as the dominant integration technology for all of the future. There are some interesting alternatives that are emerging in the market. I have chosen to categorize them based on the dominant use cases where they are used.
Serialization mechanism demands a neutral format which is platform independent and allows data interchange over heterogeneous distributed systems.
Verbose serialization formats such as XML or JSON, used in Web Services and REST, have a very poor performance. The industry is again ready to adapt high speed binary formats and lightweight Remote Procedure Call (RPC) frameworks due to high demands placed by cloud computing and growth of large scale distributed systems.
There are new set of protocols that are emerging geared towards supporting cross-language serialization with lower overhead than alternatives such as SOAP or REST due to use of binary format.
Protocol Buffers is developed by Google and are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data. They are designed to be smaller and faster than XML. Protocol Buffers is used in nearly all inter-machine communication at Google.
Apache Thrift is an RPC framework as well as binary communication protocol developed at Facebook aiming “scalable cross-language services development”. Facebook uses Apache Thrift internally for service composition. Unlike protocol buffers Thrift includes a complete stack for creating clients and servers.
Apache Avro is a language-neutral data serialization system. Avro is a preferred method to serialize data in Hadoop. Avro associates a language-independent schema with its read and write operations. Avro serializes the data into a compact binary format, which can be de-serialized by any application. Avro depends heavily on its schema. Schema is stored along with the Avro data in a file for any further processing.
With the proliferation of user devices and phones, the user interfaces are always shooting for optimal user experience, reducing the network calls and an elegant way to query and get the needed contextual data that is stored on the server, there by reducing the round trips.
GraphQL, is a query language created by Facebook. It is is designed to provide flexible syntax for describing the capabilities and requirements of data models in a client server interaction. GraphQL is a language used to query application servers that have capabilities defined as per the GraphQL specification. GraphQL is a new and evolving language and is not yet complete.
A GraphQL query is a string that is sent to a server. The server understand and fulfills the query and then returns JSON back to the client. The GraphQL queries mirror their response.
Event-driven architecture (EDA) promoting the production, detection, consumption of, and reaction to events. Building applications and systems around an event-driven architecture allows these applications and systems to be loosely coupled and more responsiveness, as event-driven systems are, by design, encourages asynchronous behavior. With the advent of Cloud and systems getting more and more distributed by nature, the need for event driven architecture is getting more and more prominent.
The Asynchronous Interactions don't really follow the traditional request/response pattern and provide different alternatives.
The Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol for message-oriented middleware. AMQP mandates the behavior of the messaging provider and client and implementations from different vendors are interoperable, similar to protocols like SMTP, HTTP, FTP, etc. making it very attractive. Open source products like RabbitMQ and Apache Quid have seen wide scale adoption, and AMQP is becoming the most extensively used open standard for passing business messages between applications or organizations.
Apache KAFKA is gaining lot of traction now a days. KAFKA was initially founded by Linkedin. Kafka is a distributed publish-subscribe messaging system that is designed to be fast, scalable, and durable.
Kafka maintains feeds of messages in topics. Producers write data to topics and consumers read from topics. Kafka is a distributed system and topics are partitioned and replicated across multiple nodes. Kafka treats each topic partition as a log. Every message in a partition is assigned a unique offset. Kafka retains all messages for a set amount of time, and consumers are responsible to track their location in each log. Kafka can support a large number of consumers and retain large amounts of data with very little overhead.
REST is still extremely popular and the most widely adopted style when it comes to building APIs. However there are interesting alternate technologies as well as use cases that don't fit right for REST. REST is being used as standardized way of building APIs across many organizations. The goal of this blog is to raise awareness around the interesting alternatives that are emerging in the market.
Opinions expressed by DZone contributors are their own.