Understanding REST Architecture: Key Concepts and Best Practices
Dive into the world of REST architecture, learn about resources, representations, HTTP methods, and web services. Explore how RESTful web services are used in creating APIs for web-based applications.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
Recitation Week 11 PRANUT JAIN
Plan for Today. REST
REST Architecture In REST Architecture everything is a resource. RESTful web services are light weight, highly scalable and maintainable and are very commonly used to create APIs for web-based applications. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
What is REST? REST stands for REpresentational State Transfer. REST is a web standards based architecture and uses HTTP Protocol for data communication. It revolves around resources where every component is a resource and a resource is accessed by a common interface using HTTP standard methods. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
In REST architecture, a REST Server simply provides access to resources and the REST client accesses and presents the resources. Each resource is identified by URIs. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
How to represent a Resource ? REST uses various representations to represent a resource like Text, JSON and XML. Which is the most popular in recent time ? HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
Revisiting HTTP AGAIN! The following HTTP methods are most commonly used in a REST based architecture. GET Provides a read only access to a resource. PUT Used to create a new resource. DELETE Used to remove a resource. POST Used to update an existing resource or create a new resource. OPTIONS Used to get the supported operations on a resource. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
Web Services A web service is a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
RESTFul Web Services Web services based on REST Architecture are known as RESTful Web Services. These web services use HTTP methods to implement the concept of REST architecture. HTTPS://WWW.TUTORIALSPOINT.COM/RESTFUL/RESTFUL_INTRODUCTION.HTM
Back to REST Architecture REST defines 6 architectural constraints which make any web service a true RESTful API. Uniform interface Client server Stateless Cacheable Layered system Code on demand (optional) HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Client-server architecture The principle behind the client-server constraints is the separation of concerns. Separating the user interface concerns from the data storage concerns improves the portability of the user interface across multiple platforms. It also improves scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Statelessness The client server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and session state is held in the client. The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Cacheability As on the World Wide Web, clients and intermediaries can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or not to prevent clients from reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client server interactions, further improving scalability and performance. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Layered system A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Code on demand Servers can temporarily extend or customize the functionality of a client by transferring executable code. Examples of this may include compiled components such as Java applets and client-side scripts such as JavaScript. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Uniform interface The uniform interface constraint is fundamental to the design of any REST service. It simplifies and decouples the architecture, which enables each part to evolve independently. Resource identification in requests Individual resources are identified in requests, for example using URIs in Web-based REST systems. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server may send data from its database as HTML, XML or JSON, none of which are the server's internal representation. Resource manipulation through representations When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource. HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
Self-descriptive messages Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Hypermedia as the engine of application state (HATEOAS) HTTPS://EN.WIKIPEDIA.ORG/WIKI/REPRESENTATIONAL_STATE_TRANSFER
HATEOAS With HATEOAS, a client interacts with a network application that application servers provide dynamically entirely through hypermedia. A REST client needs no prior knowledge about how to interact with an application or server beyond a generic understanding of hypermedia. The way that the HATEOAS constraint decouples client and server enables the server functionality to evolve independently. HTTPS://EN.WIKIPEDIA.ORG/WIKI/HATEOAS
Example This GET request fetches an account resource, requesting details in an XML representation: GET /accounts/12345 HTTP/1.1 Host: bank.example.com Accept: application/xml ... HTTPS://EN.WIKIPEDIA.ORG/WIKI/HATEOAS
Response HTTP/1.1 200 OK Content-Type: application/xml Content-Length: ... <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">100.00</balance> <link rel="deposit" href="https://bank.example.com/accounts/12345/deposit" /> <link rel="withdraw" href="https://bank.example.com/accounts/12345/withdraw" /> <link rel="transfer" href="https://bank.example.com/accounts/12345/transfer" /> <link rel="close" href="https://bank.example.com/accounts/12345/close" /> </account> HTTPS://EN.WIKIPEDIA.ORG/WIKI/HATEOAS
State change! HTTP/1.1 200 OK Content-Type: application/xml Content-Length: ... <?xml version="1.0"?> <account> <account_number>12345</account_number> <balance currency="usd">-25.00</balance> <link rel="deposit" href="https://bank.example.com/account/12345/deposit" /> </account> HTTPS://EN.WIKIPEDIA.ORG/WIKI/HATEOAS
