What is a REST API?
API (Application Programming Interface) is a set of routines, protocols, and tools for building software applications.
REST (Representational state transfer) is an architectural style for distributed hypermedia systems. It was introduced in 2000 by Roy Fielding in his dissertation.
So, a REST API or a RESTFul API is an API that implements the REST principles.
1. RFC what is it?
RFC stands for "Request for Comments." An RFC is a document that describes various aspects of the design, specifications, and working of the internet and internet-related systems.
In the context of computer networking and the Internet, an RFC is a type of publication from the Internet Engineering Task Force (IETF) and the Internet Society (ISOC). The RFC documents contain technical specifications and organizational notes for the Internet.
To know more about RFC access: https://www.ietf.org/standards/rfcs/
There are some RFCs that were created to deal with REST, the first one was RFC 2616 created in June 1999 and became obsolete by RFC7230 - RFC7235 created in June 2014, and now these RFCs are also obsolete because of the new RFC9110, RFC9111 and RFC9112 that were created in June 2022.
2. What are the most common HTTP Methods?
For more information, access RFC9110 - HTTP Methods
3. What is idempotent?
An operation is considered idempotent if performing it multiple times has the same effect as performing it once. In other words, no matter how many times you repeat the operation, the system's state remains consistent. This property is crucial for the reliability and predictability of RESTful services.
Benefits of Idempotence:
Predictable Behavior: Developers can rely on the fact that repeating an idempotent operation won't cause unexpected side effects.
Retry Mechanisms: Idempotence is useful for designing reliable systems. If a request fails, it can be safely retried without causing unintended changes.
4. What are the most common HTTP Statuses?
1xx (Informational): The request was received, continuing process
2xx (Successful): The request was successfully received, understood, and accepted
3xx (Redirection): Further action needs to be taken in order to complete the request
4xx (Client Error): The request contains bad syntax or cannot be fulfilled
5xx (Server Error): The server failed to fulfill an apparently valid request
These are some common HTTP Status:
It's crucial to know the most common HTTP status codes, as there are over 30 of them. Start by mastering the most common ones to gain a solid foundation in web development.
To know more about the HTTP status, access the RFC9110 - Status Codes
5. What is the Glory of REST?
Leonard Richardson breaks down the principal elements of a REST approach into three steps:
Level 0 (The Swap of POX): At this level there is only one endpoint, and normally it doesn't use HTTP Status, so the API will return 200 OK on all types of responses and the output will contain the error. At this level there is a single HTTP Method, usually POST.
Level 1 (Resources): At this level it will be more than one endpoint, actually one endpoint per resource, but still not using the HTTP Verbs or HTTP Status.
Level 2 (HTTP Verbs): At this level will use the HTTP Verbs and the HTTP Status
Level 3 (Hypermedia Controls): This is the most mature level of Richardson’s model, in this level the API will use HATEOAS(Hypermedia as the Engine of Application State), which encourages easy discoverability.
If you want to know more about it, read these articles:
Conclusion
To write a wonderful API, you must know RFC and best practices. This will help you create an API that follows the common standard, then it will be easy to be a customer of your API.
Another important thing is to define a REST API design. It will be easier to use your API if you have some well-known design. Try searching for famous APIs and see how they are designed to understand how to do this and what are the best practices.
Now you know what is an API and what is a REST API, but what I showed here is just the basics concepts, so keep studying 😊
References:
REST API - Design Rulebook - Mark Masse
Top comments (0)