Hi everyone
Today I thought I would do a quick post to cover RESTful APIs, and what they are. The reason for this article is that I have, on numerous occasions, encountered developers (and indeed whole teams) who have misunderstood this concept at its very core. This causes a number of problems, firstly if you don’t understand RESTful APIs fundamentally, you’re likely to encounter integration issues quite early on. Secondly, unfortunately, if you’re a candidate interviewing for a role and haven’t understood what a RESTful API is properly, you’ll come unstuck in interview.
What RESTful is not (necessarily)
- A buzzword for a JSON API
- An API with obscure functionality
What a RESTful API is, and what it has
- REST is REpresentational State Transfer, RESTful is an adjective, so a RESTful API is an API which subscribes to the REST principles
- The purpose of REST is to ensure that APIs are easy to understand at a universal level
- RESTful APIs will have end points which represent entities
- Those endpoints will respect HTTP methods (also referred to as verbs) to represent the actions you wish to take
Okay, so explain to me the HTTP methods/verbs
- GET requests represent reading this entity/collection from the data source
- POST requests represent creating an entity/collection in the data source
- PUT requests update (destructively, replacing) the entity in the data source
- PATCH requests update (partially) the entity in the data source
- DELETE requests remove the entity from the data source
How does that work in practice?
Let’s use the example of a payment provider, you may have entities such as
- api/customer
- api/payment
- api/payment/paymentId/refund
You will always need a specification, but theoretically you know that if you send a POST to endpoint/customer you will create one, if you send a PATCH you’ll partially update that customer. If you send a POST to api/payment you will create a payment, for which you will receive a reference (ID), and if you were to send a POST request to api/payment/id-you-received/refund then you would create a refund against the payment which you specified in the payment ID.
So what’s the point?
The main idea behind RESTful APIs, the same as with other standards such as PSR-X, is to unify the way in which we build APIs, so if I were to say, for example, to an organisation with whom I am going to be integrating “we have a RESTful API you can integrate with” they know, with some level of certainty, how much work there is involved in working with it – they also do not have to have an in depth understanding of my local design, architecture, etc, because the RESTful design abstracts any need for that knowledge.
In summary
RESTful APIs are great, other APIs which are not RESTful can also be great. I just wanted to help inject some clarity on the topic, although, of course, there is plenty of information on the internet around this particular methodology. If one person reads this article and gains an actual understanding of what RESTful is, then it has served its purpose.
Edit: HATEOAS further reading
Valid point raised by DarkTechnocrat on Reddit, for further reading beyond a very basic understanding on REST, you probably should read up on HATEOAS – at a quick glance this article on spring.io looks like a good place to start 🙂