Application Programming Interface
Often, API and REST come up as confusing topics to budding developers. Sometimes it’s hard to grasp the simplicity of what the differences between an API and what is considered a REST API, because technically they are not the same thing. Nowadays, most API’s follow a REST interface structures, especially Web based APIs.
What is an API?
Well, an API, simply, is an interface. A service that allows applications to interact with your program and database. This becomes increasingly useful when talking about how an application might access data from a database, but not necessarily worry about the database itself. In short, an API is a way for a program to offer up its functions and data to other applications.
An example API might have the following GET and POST requests:
There are other HTTP commands we can use. The HTTP commands are as follows
- GET – (Data Retrieval)
- POST – (Data Creation)
- UPDATE – (Data Modification)
- DELETE – (Data Deletion)
HTTP is simply the protocol that internet applications use to interact with each other. In Fieldings original dissertation, HTTP is not focused on in particular. Actually, HTTP is barely mentioned at all. The message in the original paper is that you can use REST ideology for other transports, web applications just happen to run on HTTP because, well, the internet runs on HTTP.
Ok, So what is REST?
“Rest is an architectural style that is defined by a number of constraints. REST is important because it has been described as an “after the fact” rationalization of how the web works…so in the end what REST does for us, it describes how the web works, and it explains to us also why the web works as well as it does.”
Rest is simply a way to structure API’s. One of the key features of REST is that it is “stateless;” that is, one API request does not affect the next. REST is also “resource based.” The structure is based on each resource. (e.g. students, users, blog_posts) similar to what one would consider Objects in Object Oriented Programming.
We can DELETE or UPDATE or POST, doesn’t that mean one application will affect the next?
Well, not really. What this actually means, is you can’t ‘chain’ requests. You don’t lock-up the API because you are engaging in its behavior. Each request is independent, and it does something. If you ask to make a user, you make a user. If you ask to delete as user, you delete the user, but it does not affect the way the API works.
What exactly is “Hypermedia?”
Hypermedia is like giving a web browser to a computer program. It’s how the web works, it’s why the web works so well. You can access one endpoint, from another endpoint, from another endpoint and so on. It allows you to build and add new capabilities and services without having to reconfigure a whole system of previous implementations. Hypermedia is discoverable and decentralized.
So why do we care?
REST stands for REpresentational State Transfer. It is a design concept, a set of architectural constraints. It defines an API that has:
- Base URI (mysite.com/api)
- Internet media type of data (XML, JSON, etc)
- Must be hypermedia driven (Correct use of HTTP Verbs, Status code. GET, POST, PUT and DELETE point to specific actions in the API. It also means that in any given moment the client, based on hypermedia in representation of current resource, must have all the information he needs to decide where to transit next(change its Application State)