What is rest? And the realization of restful

This article describes what is restful and what is the implementation of restful. Simply put, REST refers to a set of schema constraints and principles. Applications or designs that meet these constraints and principles are RESTful.

AD:

What is rest?

REST (Representation State Transfer) describes a schema-style network system, such as a Web application. It first appeared in 2000 with Roy Fielding's doctoral dissertation, one of the main authors of the HTTP specification. REST refers to a set of schema constraints and principles. applications or designs that meet these constraints and principles are RESTful.

The most important REST principle of a WEB application is that the interaction between the client and the server is stateless between requests. Each request from the client to the server must contain the information necessary to understand the request. If the server restarts at any point in time between requests, the client will not be notified. In addition, stateless requests can be answered by any available server, which is ideal for environments such as cloud computing. Clients can cache data to improve performance.

On the server side, application state and functionality can be categorized into various resources. A resource is an interesting conceptual entity that is exposed to the client. Examples of resources are: application objects, database records, algorithms, and so on. Each resource uses a URI (Universal Resource Identifier) to get a unique address. All resources share a unified interface to transfer state between the client and the server. Standard HTTP methods are used, such as GET, PUT, POST, and DELETE. Hypermedia is the engine of application state, and resources are interconnected through hyperlinks.

Another important REST principle is a hierarchical system , which means that a component cannot understand a component outside the middle tier it interacts with. By restricting system knowledge to a single layer, you can limit the complexity of the entire system and promote the underlying independence.

When the constraints of the REST schema are applied as a whole, an application is generated that can be scaled to a large number of clients. It also reduces the interaction latency between the client and the server. The unified interface simplifies the entire system architecture and improves the visibility of interactions between subsystems. REST simplifies the implementation of clients and servers.

RESTful implementations: RESTful Web Services with RPC-style Web services

Knowing what is what is rest, let's look at the implementation of restful. Recently, SOAP-based WEB services built using RPC-style schemas have become the most common approach to implementing SOA. The RPC-style WEB service client sends an envelope full of data, including method and parameter information, to the server via HTTP. The server opens the envelope and executes the specified method using the incoming parameters. The results of the method are packaged into an envelope and sent back to the client as a response. The client receives a response and opens the envelope. Each object has its own unique method and an RPC style Web service that exposes only one URI, which represents a single endpoint. It ignores most of the HTTP features and only supports the POST method.

The RESTful approach to WEB Services has become the most common alternative because of the lightweight and the nature of the data being transmitted directly over HTTP. Clients can be implemented in a variety of languages, such as Java programs, Perl, Ruby, Python, PHP, and javascript[including Ajax]. RESTful Web Services can often be accessed through automated clients or applications that represent users. However, the simplicity of this service allows users to interact directly with them, build a GET URL using their Web browser, and read the returned content.

In a REST-style Web service, each resource has an address. The resource itself is the target of the method invocation, and the list of methods is the same for all resources. These methods are standard methods, including HTTP GET, POST, PUT, DELETE, and may include headers and OPTIONS.

In the RPC-style architecture, the focus is on the method, while in the REST-style architecture, the focus is on the resource-the information fragment will be retrieved and manipulated using the standard method (in the form of representations). The resource representation is used to interconnect hyperlinks in representations.

Leonard Richardson and Sam Ruby introduced the term REST-RPC hybrid architecture in their book RESTful Web Services. Instead of using envelope wrapping methods, parameters, and data, the REST-RPC Hybrid Web service transmits data directly over HTTP, similar to restful Web services. However, it does not use the standard HTTP method to manipulate resources. It stores method information in the URI portion of the HTTP request. Several well-known WEB services, such as Yahoo's Flickr API and the Del.icio.us API, use this hybrid architecture.

RESTful implementations: The Java framework for RESTful WEB services

There are two Java frameworks that can help build RESTful Web services. The Restlet (see Resources) developed by Erome Louvel and Dave Pawson are lightweight. It implements concepts such as resources, representations, connectors, and media types for a variety of RESTful systems, including WEB services. In the Restlet framework, both the client and the server are components. Components communicate with each other through connectors. The most important class of the framework is the abstract class Uniform and its specific subclass Restlet, which subclasses are specialized classes, such as application, Filter, Finder, Router, and Route. These subclasses can work together on validation, filtering, security, data transformation, and routing incoming requests to the appropriate resources. The Resource class generates a representation of the client.

JSR-311 is the specification of Sun Microsystems, which defines a set of Java APIs for developing RESTful Web services. Jersey is the reference realization of JSR-311.

JSR-311 provides a set of annotations that all related classes and interfaces can use to present Java objects as WEB resources. The specification assumes that HTTP is the underlying network protocol. It uses annotations to provide a clear mapping between the URI and the corresponding resource class, and the mapping between the HTTP method and the Java object method. The API supports a wide range of HTTP entity content types, including HTML, XML, JSON, GIF, JPG, and more. It will also provide the plug-in functionality required to allow other types to be added through the application using standard methods.

RESTful implementations: Building a multi-tiered architecture for restful WEB services

RESTful Web Services and Dynamic Web applications are similar in many ways. Sometimes they provide the same or very similar data and functions, despite the different types of clients. For example, the online e-Commerce classification website provides users with a browser interface for searching, viewing, and ordering products. It is useful if you also provide WEB services for companies, retailers, and even individuals to automatically order products. As with most dynamic Web applications, Web services can benefit from the separation of concerns from multiple architectures. Business logic and data can be shared by automated clients and GUI clients. The only difference is the nature of the client and the presentation layer of the middle tier. In addition, separating business logic from data access enables database independence and provides plug-in capabilities for various types of data storage.

Figure 1 shows the Automation client, including scripts written in Java and in a variety of languages, including Python, Perl, Ruby, PHP, or command-line tools such as curl. Ajax, Flash, JavaFX, GWT, blogs, and wikis that run in the browser and run as a RESTful Web service consumer belong to this column because they all run in an automated style on behalf of the user. The Automation Web service client sends an HTTP response to the Resource Request Handler at the Web layer. The stateless request of the client contains method information in the header, that is, POST, GET, PUT, and DELETE, which in turn maps to the corresponding operation of the resource in the Resource request Handler. Each request contains all the necessary information, including the credentials that the Resource request Handler uses to process requests.

After receiving the request from the Web service client, Resource request Handler requests the service from the business logic layer. Resource Request Handler Identify all conceptual entities, which the system exposes as resources and assigns a unique URI to each resource. However, a conceptual entity does not exist at that level. They exist at the business logic layer. The Resource Request Handler can be implemented using Jersey or other frameworks (such as Restlet), which should be lightweight and delegate a lot of responsibility to the business layer.

Ajax and RESTful Web services are inherently complementary to each other. They can all take advantage of a number of WEB technologies and standards, such as HTML, JavaScript, browser objects, Xml/json, and HTTP. Of course, there is no need to purchase, install, or configure any major components to support the interaction between the Ajax front-end and RESTful Web services. RESTful Web Services provide Ajax with a very simple API to handle the interactions between resources on the server.

The Web browser client in Figure 1 serves as the front end of the GUI and provides display functionality using the HTML generated by the Browser Request Handler in the presentation layer. Browser requester Handler can use the MVC model (JSF, Struts, or Spring are examples of Java). It accepts requests from the browser, requests services from the business logic layer, generates representations, and responds to the browser. Represents the use that the user displays in the browser. Represents not only the content, but also the displayed properties, such as HTML and CSS.

Business rules can be centralized to the business logic layer, which acts as the middle tier for data exchange between the presentation layer and the data access layer. Data is provided to the presentation layer in the form of a domain object or a value object. Decoupling Browser request Handler and Resource request Handler from the business Logic layer helps facilitate code reuse and enables flexible and extensible architectures. In addition, because new REST and MVC frameworks can be used in the future, it becomes easier to implement them without rewriting the business logic layer.

The data access layer provides interaction with the data storage layer and can be implemented using DAO design patterns or object-relational mapping solutions such as Hibernate, OJB, or IBATIS. As an alternative, components in the business layer and data access layer can be implemented as EJB components and supported by the EJB container, which facilitates the component lifecycle and manages persistence, transaction, and resource configuration. However, this requires a Java EE-compliant application server (such as JBoss) and may not be able to handle Tomcat. The role of this layer is to separate the data access code from the business logic for different data storage technologies. The data access layer can also be used as an integration point to connect to other systems and can be a client for other WEB services.

Data storage tiers include database systems, LDAP servers, file systems, and enterprise information systems (including legacy systems, transaction processing systems, and enterprise resource planning systems). With this architecture, you can begin to see the power of RESTful Web Services, which provide the flexibility to become a unified API for any enterprise data store, exposing vertical data to user-centric Web applications and automating batch reporting scripts.

What is rest: concluding remarks

REST describes an architecture-style interconnected system, such as a WEB application. When a REST constraint is applied as a whole, a simple, extensible, efficient, secure, and reliable architecture is generated. Because of its simplicity, light weight, and the nature of transmitting data directly over HTTP, RESTful Web services have become one of the most promising alternatives to SOAP-based services. Multi-tiered architectures for Web services and dynamic Web applications enable a clear separation of reusability, simplicity, scalability, and component responsiveness. Ajax and RESTful Web services are inherently complementary to each other. Developers can easily use Ajax and RESTful Web services to create rich interfaces together.

What is rest? And the realization of restful