I know, the titles need some work. I started looking at PHP Idempotency and the first definition said I should look at REST instead, so here we are.
REST (and RESTful) come up quite a bit in the course I’m taking but so far, nothing has been explained. Thanks to the power of Google, I now know more than I did before.
REST stands for “Representational State Transfer”, and is often described as a REST API / RESTful API. An API (Application Programming Interface), in its simplest terms, is a way for two things to talk to each other – data is transferred back and forth, and the API acts as the bridge between the things. I said “things” instead of “programs” in this case – but I would say it’s safe to say at the end of the day it’s all a program doing the heavy lifting. The reason I said things is because the definitions I’m reading say systems and computers – and what really is a system or a computer, but a piece of hardware that contains a program.
So to expand on the concept of API being a way for two things that talk to each other, a RESTful API is a set of standards on the way the API is created. There are others that I won’t go into right now (such as SOAP or XML-RPC), for this article we just need to know that REST is one of a handful of potential options. What sets REST APIs apart from the other APIs mentioned above is it’s less strict in the way REST does things – provided the API in question follows six design principles.
Uniform Interface: All API requests should look the same regardless of where the request comes from.
Client-Server Decoupling: Client and Server applications must be completely independent. Basically, the client can only communicate with the server via the URI of the requested resource.
Stateless: REST APIs do not require server-side sessions & servers do not store any data related to a client request.
Cacheable: Resources should be cachable on the server or client-side & the server should indicate whether or not caching is allowed for the delivered resource.
Layered System Architecture: We shouldn’t assume that the client and server connect directly to each other – there may be many intermediaries in the connection. The API therefore needs to be designed so neither the client or server know if they’re talking directly, or through an intermediary.
Code on Demand: This one is apparently optional. From time to time, responses can contain executable code such as Java applets.
I feel that based on those six principles alone, I’m way above my pay grade right now. The only takeaway that I need to know at this point in my journey is uniformity. REST came up as we were discussing common conventions, such as “show and destroy” when it comes to terminology surrounding the application. We’re not creating an API per se, but we’re trying to follow commonly accepted conventions. Considering I’ve barely scratched the surface here, I think it made sense that it wasn’t described what REST was as it came up in the course. Going any further would cause needless confusion – which means I’ll stop here as well.
For more reading; I’ll link two sources I used:
