Table of Contents
Representational State Transfer (REST), first created by Roy Fielding in 2000, has become quite a prevailing force in the industry thanks to its ease of use. But in this day and age, there are plenty of API design styles to choose from, including GraphQL, SOAP, and gRPC, to name a few. As application demands and APIs continue to evolve, this begs the question: is REST still a viable design choice for developers today?
Built to Last
Unlike its contemporaries, REST was made by Fielding with long-term usability in mind. In his own words, “every detail [was] intended to promote software longevity and independent evolution.” One way that REST exhibits this characteristic is its statelessness, or in how it separates the user interface from the data storage and the server.
This separation between client and server provides several advantages. For one, it makes REST APIs independent of platforms or languages, making it a highly portable design choice. Developers could switch between Node.js, Java, PHP, or Python servers without much difficulty. Because there is no session-related dependency, any server can handle any request, meaning REST APIs can be scaled indefinitely. It is also more flexible since each resource is assigned an individual URL and the front and back ends can be kept on different servers.
These benefits make it highly likely that REST will continue to see widespread adoption for decades to come.
Simple to Use
Another advantage of being stateless is that REST can remove all state synchronization logic on the server side, making it far less complex. Because of its relative simplicity, REST is easy for most developers to pick up, as it relies on standard HTTP and CRUD functions. Hence, REST uses basic verbs such as “get” or “remove” which not only avoids ambiguity, but also makes it clear to developers what each function does. Developers can also use the visual editor included in many an effective API Design, Planning & Modeling Tool for a clearer, less-cluttered look at their code.
Additionally, there are many available REST client libraries in multiple programming languages, making it easy for developers to find the code they need. REST also boasts a large and active tooling community that offers support for developers of all experience levels. Hence, it is not difficult to find help when troubleshooting any errors or figuring out how to pull a certain feature off. Additionally, because there are so many developers comfortable with REST, companies won’t have a problem when it comes to recruitment.
Is REST Always the Best Option?
Though REST can serve as a great foundation for most APIs, it is not best-suited for every situation. Generally speaking, REST may not work for scenarios requiring optimal performance and flexible data retrieval patterns. It is not as efficient for event- or push-driven scenarios such as messaging APIs due to its constant polling of users. In these cases, GraphQL or gRPC may be a better fit instead.
Hence, the choice to use REST should be done on a case-by-case basis. Developers can do this by taking a step back and seeing what the design style can offer, as well as carefully considering its strengths and weaknesses. These should then be weighed against the product’s requirements. With all these in mind, would using REST fit in the context in which the end-users will be using the resulting API?
While REST may not be an end-all-be-all solution, it is certainly a competent design choice that can serve a wide berth of uses. Ultimately, REST should be viewed as a tool just like any other API style. As such, developers should not make the mistake of trying to twist their product to suit the design choice. Rather, the API style should suit the project objectives, not the other way around.
