# REST API > **What Is A REST API** > **\- Redhat** > https://www.redhat.com/en/topics/api/what-is-a-rest-api > **\- IBM Cloud** > https://www.youtube.com/watch?v=lsMQRaeKNDk > **\- NordicAPI** > https://nordicapis.com/all-you-need-to-know-about-rest-api-design/ ### API An API is a set of definitions and protocols for building and integrating application software. It’s sometimes referred to as **a contract between an information provider and an information user**—establishing the content required from the consumer (the call) and the content required by the producer (the response). In other words, if you want to interact with a computer or system to retrieve information or perform a function, an API helps you communicate what you want to that system so it can understand and fulfill the request. You can think of an API as a mediator between the users or clients and the resources or web services they want to get. It’s also **a way for an organization to share resources and information while maintaining security, control, and authentication**—determining who gets access to what. ### REST API *REpresentational State Transfer* - Simple, Standard - Scalable, Stateless - High Performance, Support Caching A rest api endpoint can be: ![](https://i.imgur.com/Yq1VQrh.png) HTTP methods for REST api: - POST - GET - PUT - DELETE A request typically consists of - a header (contains api keys and authentication data) - an operation (one of the http methods) - an endpoint - some parameters or body (data sent with the request) ![](https://i.imgur.com/eqFLaMj.png) When a client request is made via a RESTful API, it transfers a representation of the state of the resource to the requester or endpoint. This information, or representation, is delivered in one of several formats via HTTP: JSON (Javascript Object Notation), HTML, XLT, Python, PHP, or plain text. In order for an API to be considered RESTful, it has to conform to these criteria: - A **client-server** architecture made up of clients, servers, and resources, with requests managed through HTTP. Each of these components is independent and can be modified independently. - **Stateless** client-server communication, meaning no client information is stored between get requests and each request is separate and unconnected. All of the state data are managed from the client-side. A request from the application contains all of the information necessary for their processing. - **Cacheable data** that streamlines client-server interactions.This lets clients and infrastructures decide if they want to cache information or not to improve performance. - A **uniform interface** between components so that information is transferred in a standard form. This requires that - - resources requested are identifiable and separate from the representations sent to the client. - resources can be manipulated by the client via the representation they receive because the representation contains enough information to do so. - self-descriptive messages returned to the client have enough information to describe how the client should process it. - hypertext/hypermedia is available, meaning that after accessing a resource the client should be able to use hyperlinks to find all other currently available actions they can take. - A **layered system**. Components of a REST system cannot see beyond their layer. This makes it easier to add additional levels of security and load-balancing for enhanced performance. - **Code-on-demand** (optional): the ability to send executable code from the server to the client when requested, extending client functionality. * * * > **REST APIs - FreeCodeCamp** > https://www.freecodecamp.org/news/rest-apis/ * * * > **What Is A RESTful API?** Explanation of REST & HTTP - Traversy Media > https://youtu.be/Q-BpqyOT3a8 > **Statelessness** > https://stackoverflow.com/questions/3105296/if-rest-applications-are-supposed-to-be-stateless-how-do-you-manage-sessions > Statelessness means that every HTTP request happens in complete isolation and the server does not store any state about the client session on the server side. > When the client makes an HTTP request, it includes all the information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have to send it again in subsequent request. A stateless application is also easy to cache. > The client's application state should never be stored on the server, but passed around from the client to every place that needs it. That is where the ST in REST comes from, State Transfer. You transfer the state around instead of having the server store it. This is the only way to scale to millions of concurrent users. > **CRUD vs REST** > https://softwareengineering.stackexchange.com/questions/120716/difference-between-rest-and-crud > https://nordicapis.com/crud-vs-rest-whats-the-difference/ > https://tyk.io/rest-never-crud/ > *Create, Read, Update, and Delete — CRUD* — are the four major functions for interacting with database applications. REST operates on resource representations, each identified by an URL. > REST and SOAP in plain english - StackOverflow > https://stackoverflow.com/questions/209905/representational-state-transfer-rest-and-simple-object-access-protocol-soap > Alternatives to REST API > https://stackoverflow.com/questions/36101446/alternatives-to-rest-api-pattern > Netflix uses FALCOR, Facebook uses GraphQL > https://www.restapitutorial.com/lessons/httpmethods.html#:~:text=The%20primary%20or%20most-commonly,but%20are%20utilized%20less% #