Last active
August 11, 2021 18:05
-
-
Save bbrt3/9b8f583ad97ee7bb0275e204340f353c to your computer and use it in GitHub Desktop.
REST
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* | |
REST (Representational State Transfer) | |
. | |
It is an architectural style of distributed system. | |
It is based upon the set of principles that describes | |
how network resources are defined and addressed. | |
There are 39 total HTTP verbs. | |
REST uses POST, GET, PUT, PATCH, DELETE and OPTIONS. | |
CLIENT --REQUEST--> DATABASE | |
REST API | |
CLIENT <-RESPONSE-- DATABASE | |
RESTful services use HTTP/HTTPS to communicate | |
REST uses external systems as a web resources identified | |
by URIs (Uniform Resource Identifiers) | |
RULES OF REST | |
a) Uniform interface | |
You must cedice APIs interface for resources inside the system | |
which are exposed to API consumers and follow it. | |
A resource in the system should have only one logical URI | |
and that should provide a way to fetch related or additinal data. | |
Any single resource should not be too large and contain each and everything | |
in its representation. | |
Resource representation should follow specific guideliness such as | |
naming conventions, link formats, or data format (XML/JSON). | |
All resources should be accessible through a common approach | |
such as HTTP GET. | |
Once a developer becomes familiar with one of your APIs, | |
he should be able to follow a similar approach for other APIs. | |
b) Statelessness | |
No client context shall be stored on the server between requests. | |
The client is responsible for managing the state of the application. | |
c) Client-Server | |
Client and server applications must be able to evolve separately, | |
without any dependency on each other. | |
Client should only know URIs, and that's all. | |
Servers and clients may also be replaced and developed independently, | |
as long as interface between them is not altered. | |
d) Cacheable | |
Caching brings performance improvements for the client-side | |
and better scope for scalability for a server because the load has reduced. | |
In REST, caching shall be applied to resources when applicable. | |
Well-managed caching partially or completely eliminates some client-server interactions | |
further improving scalability and performance. | |
e) Layered System | |
REST allows us to use a layered system architecture, where we deploy | |
the APIs to server A, store data on server B, and authenticate on server C. | |
A client cannot tell whether he is connected directly to the end server, | |
or some other one used on the way. | |
*/ |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment