There are three main characteristics of HTTP Request Methods:
1. Safe
2. Idempotent
3. Cacheable
Let's talk about them in this thread. π§΅ππ»
1. Safe
2. Idempotent
3. Cacheable
Let's talk about them in this thread. π§΅ππ»
πΈ Safe
We can call an HTTP request method safe if it doesn't affect the server's state.
The safe methods request the server to send data without performing any modification to the original data. Hence safe methods accomplish read-only operations.
We can call an HTTP request method safe if it doesn't affect the server's state.
The safe methods request the server to send data without performing any modification to the original data. Hence safe methods accomplish read-only operations.
Even though they are read-only operations, they sometimes cause a change in server state; the server can update its statistics.
One thing to note here is that the safe methods never request the server to change its state.
One thing to note here is that the safe methods never request the server to change its state.
πΈ Idempotent
Idempotent methods have no side effects on the server. We can call them in a row, and they guarantee that they will not affect the server state (except for keeping statistics).
GET, HEAD, OPTIONS, PUT, DELETE, and TRACE methods are idempotent.
Idempotent methods have no side effects on the server. We can call them in a row, and they guarantee that they will not affect the server state (except for keeping statistics).
GET, HEAD, OPTIONS, PUT, DELETE, and TRACE methods are idempotent.
All safe methods are idempotent, but not all idempotent methods are safe.
To be an idempotent method, only the state of the server matters, not the code returned by it. Hence DELETE method is idempotent but not safe.
To be an idempotent method, only the state of the server matters, not the code returned by it. Hence DELETE method is idempotent but not safe.
β οΈ Another thing to note here is that the client-side ensures the validation of idempotence. The bad codebase can shatter the idempotent constraint.
πΈ Cacheable
As the term suggests, we can call HTTP response methods cacheable if it is possible to cache the response for later use.
However, there are some constraints: ππ»
As the term suggests, we can call HTTP response methods cacheable if it is possible to cache the response for later use.
However, there are some constraints: ππ»
Constraints for an HTTP response to be cached:
1. Method should be cacheable. Only GET and HEAD methods are cacheable.
2. PUT and PATCH can be cached if the `Content-Location` header is set.
1. Method should be cacheable. Only GET and HEAD methods are cacheable.
2. PUT and PATCH can be cached if the `Content-Location` header is set.
3. Only a few status codes are cacheable: 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501.
4. Headers like `Cache-Control` can be used to prevent caching.
4. Headers like `Cache-Control` can be used to prevent caching.
With that being said, that's pretty much it for this thread.
Visit RapidAPI Hub (RapidAPI.com/hub?utm_sourceβ¦) and build a strong understanding of APIs by playing around with over 35K excellent APIs.
Visit RapidAPI Hub (RapidAPI.com/hub?utm_sourceβ¦) and build a strong understanding of APIs by playing around with over 35K excellent APIs.
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
γ
