RESTful and RESTful implementations

RESTful and RESTful implementations

What is REST?

REST (REpresentation State Transfer) describes an architecture-style network system, such as a web application. It first appeared in Roy Fielding's doctoral thesis in 2000. He is one of the main writers of HTTP specifications. REST refers to a set of architecture constraints and principles. Applications or designs that meet these constraints and principles are RESTful.

The most important REST principle for Web applications 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 time point between requests, the client will not be notified. In addition, stateless requests can be answered by any available server, which is suitable for cloud computing and other environments. The client can cache data to improve performance.

On the server side, application status and functions can be divided into various resources. A resource is an interesting conceptual entity that is made public to the client. Resource examples include application objects, database records, algorithms, and so on. Each Resource uses URI (Universal Resource Identifier) to obtain a unique address. All resources share a unified interface for transmission between the client and server. Standard HTTP methods are used, such as GET, PUT, POST, and DELETE. Hypermedia is the engine of application status. Resources are represented by hyperlink.

Another important REST principle is the hierarchical system, which means that the component cannot understand components other than the middle layer of its interaction with it. By limiting the system knowledge to a single layer, you can limit the complexity of the entire system and promote the independence of the underlying layer.

When the constraints of the REST architecture are used as a whole application, an application that can be extended to a large number of clients will be generated. 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 interaction between subsystems. REST simplifies the implementation of clients and servers.

Content navigation

RESTful implementation: RESTful Web Services and RPC-style Web Services

After learning about what REST is, let's look at the implementation of RESTful. Recently, SOAP-based Web Services built using the RPC style architecture have become the most common method for SOA implementation. The RPC-style Web service client sends an envelope (including method and parameter information) filled with data to the server over HTTP. The server opens the envelope and uses the input parameters to execute the specified method. The result of the method is packaged into an envelope and sent back to the client as a response. The client receives the response and opens the envelope. Each object has its own unique method and only exposes RPC-style Web Services with one URI. URI represents a single endpoint. It ignores most of HTTP features and only supports the POST method.

Because of its lightweight and direct data transmission over HTTP, the RESTful method of Web services has become the most common alternative. You can use a variety of languages (such as Java programs, Perl, Ruby, Python, PHP, and Javascript [including Ajax]) to implement the client. RESTful Web services can generally be accessed through an automatic client or an application representing a user. However, the simplicity of this service allows users to directly interact with it, using their Web browser to build a get url and read the returned content.

In a REST-style Web Service, each resource has an address. Resources are the targets of method calls, and the method list is the same for all resources. These methods are all standard methods, including http get, POST, PUT, DELETE, and HEADER and OPTIONS.

In the RPC style architecture, the focus is on methods, while in the REST style architecture, the focus is on resources-the standard method will be used to retrieve and operate information fragments (using the representation form ). The resource representation uses hyperlinks in the representation.

Leonard Richard and Sam Ruby introduced the mixed architecture of the term REST-RPC in their book RESTful Web Services. REST-RPC Hybrid Web Services transfer data directly over HTTP instead of using envelope packaging methods, parameters, and data, which is similar to REST-style Web Services. However, it does not use standard HTTP methods to operate resources. It stores method information in the URI of an HTTP request. Several well-known Web services, such as Yahoo's Flickr API and del. icio. us API, all use this hybrid architecture.

Content navigation

RESTful implementation: Java framework of RESTful Web Services

There are two Java frameworks to help build RESTful Web Services. Restlet developed by erome Louvel and Dave Pawson (see references) is lightweight. It implements concepts such as resources, representations, connectors, and media types for various RESTful systems, including Web Services. In the Restlet framework, both the client and server are components. Components communicate with each other through connectors. The most important class of this framework is the abstract class Uniform and its specific subclass Restlet. The subclass of this class is a specialized class, such as Application, Filter, Finder, Router, and Route. These sub-classes can process verification, filtering, security, data conversion, and route incoming requests to corresponding resources. The Resource class generates the client representation.

JSR-311 is Sun Microsystems specification that can define a set of Java APIs for developing RESTful Web Services. Jersey is a reference implementation for JSR-311.

The JSR-311 provides a set of annotations that can both be used to present Java objects as Web resources. This specification assumes that HTTP is the underlying network protocol. It uses annotations to provide clear mappings between Uris and corresponding resource classes, as well as mappings between HTTP methods and Java object methods. API supports a wide range of HTTP entity content types, including HTML, XML, JSON, GIF, and JPG. It also provides the required plug-in functionality to allow additional types to be added through the application using standard methods.

RESTful implementation: Build a multi-layer architecture of RESTful Web Services

RESTful Web Services and dynamic Web applications are similar in many aspects. Sometimes they provide the same or very similar data and functions, despite the different types of clients. For example, an 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. Like most dynamic Web applications, Web services can benefit from the separation of concerns in a multi-layer architecture. The business logic and data can be shared by the automatic client and GUI client. The only difference lies in the nature of the client and the presentation layer of the intermediate layer. In addition, separating business logic from data access enables database independence and provides plug-ins for various types of data storage.

Figure 1 shows the automated client, including Java and scripts written in various languages, including Python, Perl, Ruby, PHP, or command line tools, such as curl. Ajax, Flash, JavaFX, GWT, blog, and wiki that run in a browser and run as a RESTful Web service consumer all belong to this column, because they all represent users running in an automated style. The automated Web service client sends an HTTP Response to the Resource Request Handler at the Web layer. The client's stateless Request contains method information in the header, namely POST, GET, PUT, and DELETE, which maps to the corresponding operations of resources in the Resource Request Handler. Each Request contains all required information, including the creden。 used by the Resource Request Handler to process the Request.

After receiving the Request from the Web service client, the Resource Request Handler requests the service from the business logic layer. Resource Request Handler identifies all conceptual entities. The system discloses these entities as resources and assigns a unique URI to each Resource. However, conceptual entities do not exist in this layer. They exist in the business logic layer. You can use Jersey or other frameworks (such as Restlet) to implement Resource Request Handler. It should be lightweight and delegate a large amount of duties to the business layer.

Content navigation

Ajax and RESTful Web services are complementary in nature. They can all use a large number of Web technologies and standards, such as HTML, JavaScript, browser objects, XML/JSON, and HTTP. Of course, you do not need to purchase, install, or configure any major components to support interaction between the Ajax front-end and RESTful Web Services. RESTful Web Service provides a simple API for Ajax to process the interaction between resources on the server.

In Figure 1, the Web Browser client acts as the front-end of the GUI and uses the HTML generated by Browser Request Handler in the presentation layer to provide the display function. Browser Requester Handler can use the MVC model (JSF, Struts, or Spring are examples of Java ). It receives requests from the browser, requests the service from the business logic layer, generates a representation, and responds to the browser. It is displayed in the browser. It not only contains content, but also display attributes, such as HTML and CSS.

Business Rules can be centralized to the business logic layer, which acts as the middle layer 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 value object. Decoupling Browser Request Handler and Resource Request Handler from the business logic layer facilitates code reuse and implements a flexible and scalable architecture. In addition, since new REST and MVC frameworks can be used in the future, it is easier to implement them without the need to rewrite the business logic layer.

The data access layer provides interaction with the data storage layer, which can be implemented using the DAO design mode or object-relationship ing solution (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 get support from EJB containers. This container can facilitate the life cycle of components, manage persistence, transactions, and resource configuration. However, this requires an application server that complies with Java EE (such as JBoss) and may not be able to process Tomcat. This layer is used to separate 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 used as a client for other Web Services.

The data storage layer includes 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 start to see the power of RESTful Web services, which can flexibly become a unified API for any enterprise data storage, in this way, vertical data is exposed to user-centered Web applications and scripts are automatically reported in batches.

What is REST: Conclusion

REST describes an architecture-style interconnected system (such as Web applications ). A simple, scalable, effective, secure, and reliable architecture is generated when the REST constraints are used as a whole application. Thanks to its simplicity, lightweight, and direct data transmission over HTTP, RESTful Web services have become the most promising alternative to SOAP-based services. The multi-layer architecture for web Services and dynamic Web applications can achieve clear separation of reusability, simplicity, scalability, and component responsiveness. Ajax and RESTful Web services are complementary in nature. Developers can easily use Ajax and RESTful Web services to create rich interfaces.