"I’ve always been interested in invisible worlds, and I like to visit digital worlds, you know, any world that’s imposed on us."
RESTful API represents a famous app programming interface. In the name REST API, web API or just API stands for the programming interface that makes interaction with other RESTful web services possible.
Roy Fielding was the one who created this app programming interface that has REST architectural style, and this computer scientist definitely knew how to invent something that'll be capable to build and integrate different protocols into just one software.
Sometimes, people connect REST API to something else, like a contract that serves as a connection between information users and information providers. So, the content that is required from the consumer would be best explained as a call, while the one that comes from the producer would be the response.
Confusing? Let's explain all this in one example. What would API design for some weather service look like? Here, the user is supplying a zip code. API recognizes that. What does the producer do? They reply with an answer, but such an answer that is consisted of two parts. For example, in this weather service story, the first answer would be high temperature, and the second answer would be low temperature.
Overall, API is capable to help you with many communications, like when you are trying to communicate with some system or a computer. Want it to do a specific function? API will help you achieve it. Fulfilling the request is easier by using REST API.
API is easily understandable as a mediator. When users want to get certain web services, API allows them to do so.
Luckily, API doesn't only serve as a mediator between the service and the user, but it also makes that connection secure. Authentication and control parts, as well as information and resources, are controlled through API, so you can be completely sure who gets access to what.
Wondering if it would be useful to know the specifics of caching. Luckily, with API, you don't actually need to know how the source is retrieved. You also don't need to worry about where it comes from. Therefore, API makes it easier for everyone to try it and takes all the advantages it can offer.
Realized that we have mostly talked about the API part only. Yes, but don't worry, we are going to share a lot of useful information about the REST part now.
Architectural constraints are what makes REST. These constraints are neither a standard nor a protocol. So, if you are an API developer, or just wondering how the REST part can be implemented, know that there are numerous variations to try.
Let's say that a client has made some requests through REST API. What happens next is that those requests are actually transferred through a representation that comes from a specific resource, and later on sent to its endpoint or to a requester itself.
Think of representation as information. What happens with it next is that it's sent in some specific formats, like JavaScript Object Notation (HTTP: JSON), Python, PHP, HTML, plain text, and more. Yet, one of these formats is definitely the most liked among users because it can be readable both by computers and people, and that is, of course, JavaScript Object Notation, or simply JSON.
Okay, now that we understood how the REST part sends information, there is something else that may be important for you to know here. Headers and parameters. They are very important when we talk about the HTML parts of different REST API requests. These are the ones that carry and bring important things, such as authorization, cookies, caching, and metadata.
Being able to complete these criteria is a must for API to become RESTful:
1. A layered system that's capable to organize all types of servers. Load-balancing and security would be good examples of this.
2. Uniform interface. This is important so information can be processed in its own standard form.
3. Cacheable data. Why do we need this? Simply because it's capable to complete different client-server interactions.
4. Stateless communication. This is related to client-server interactions as well. It's important that there is no information by the client that is being stored between the requests.
5. And last, but most important - a client-server-oriented architecture. Of course, and as mentioned and explained above, it consists of different clients, services, and the resources they need for interaction and communication. Keep in mind that such requests are always done through HTTP.
Optionally, you can also think of code-on-demand ability facts. Extending client functionality is not a must, but it definitely adds some points when we want to make API RESTful.
