APIs are a huge part of development today and one of the most common types of API out there is a RESTful API. REST stands for representational state transfer, which is a software architecture that imposes conditions on how an API should work. Essentially, it was created as a set of guidelines for how communications should work between disparate systems on a complex communication network (like the internet). REST is implemented atop HTTP and uses the standards in the underlying protocol as part of the standards for communication. In a RESTful API, client and server applications are considered to be independent, that is, details from one should not leak into the other, to the extent possible. This also implies that API calls for the same resource should look the same regardless of where they come from – indeed this is required to decouple the client and the server.

RESTFul APIs are built around the inherent statelessness of HTTP. That is, a persistent connection between the client and server is not assumed. This has profound architectural implications in regards to how resources are accessed and mutated. In order to make this disconnected architecture perform well across the internet, this also means that caching will be used heavily. Caching implies further architectural constraints around resource access, as well as careful coding server side to ensure that items are cached (and removed from cache) appropriately. This helps both client side speed and server side scalability. In addition, the lack of a session makes it far easier to spread a workload across multiple servers, as there is no need to synchronize state between them or keep sessions sticky.

Restful APIs are pretty much bog standard web technology at this point. Not only do complex frontends use them, but clients, QA, and other parts of your own system will often do so as well. While Rest APIs are generally standard at this point, there are a lot of mistakes you can make when designing them that make it harder to use your API, create excess load on the server, or just generally increase the frustration level of all involved parties. Certain antipatterns also look good initially, but end up causing problems later when your system gets more users, or more HTTP savvy integrators working with it. We hope this brief overview is enough to save you some time up front on your next API project.