Build restful web Apps with spring MVC

Transferred from: http://fancy888.iteye.com/blog/1629120

For the MIS system running on the network, processing the data is the main task of the whole system, we can see that over 80% of the code is processing the crud operation of the data. The use of a framework structure that makes processing data easy and understandable is an issue that most developers, especially architects, have been thinking about.

Rest (representational state Transfer) is a programming style, especially designed and developed for Web applications, and using rest can significantly reduce the complexity of development and increase the scalability of the system.

Rest is a unique programming style, unlike the MVC emphasis on the role layering concept, rest emphasizes the use of uniform rules to standardize the operation of the resources, the two are complementary, consistent with each other, using the MVC Architecture collocation Rest Programming Style Network-based MIS system will be not far from the mainstream. This article focuses on the core rules of the rest programming style, and combines spring MVC to describe the code morphology of rest in real-world applications.

Developing Web applications using restful styles emphasizes the following rules:

1. All things on the network are abstracted as resources (resource);
2. Each resource corresponds to a unique resource identifier (resource identifier);
3. Operation of the resource via a common connector interface (generic connector interface);
4. The various operations on resources will not change the resource identification;
5. All operations are stateless (stateless).

First, in my opinion, the resources in the rest definition are the data that the application processes. For example, the order management system, the order information is the data, the same customer information and product information is also the data, in the rest it seems that the data are resources.

Rest emphasizes that a resource must have a unique name and ID, which is used to differentiate between different resources, and the ID is used to locate only one data in a homogeneous resource. In rest, these rules are described by URIs. Or take the order system above as an example, we set the order information name to order, customer information for customers, goods information for product, then there are several URI design:

    <!-- Identify all the order information  -       http://www.coolfancy.com/rest/order            <!-- identify all customer information  --      Http://www.coolfancy.com/rest/customer             <!-- identification of cargo information with ID 1  -       HTTP://WWW.COOLFANCY.COM/REST/PRODUCT/1  

We can see the features of the rest style URI design: http://host/context/Resource name/[resource ID]. Where the resource name is a required option, the resource ID can be omitted, and the resource ID is used to identify all data for a class of resources.

With a resource and a URI to identify the resource, rest uses the connector to identify the operation on the resource. Here, the operation of the resource is divided into query/get, create, delete, modify four kinds. In a network programming environment, rest uses the HTTP protocol as the connector, using the HTTP method (request method) to identify the type of operation:

• HTTP get: Querying and retrieving resources;
• HTTP POST: Creating resources;
• HTTP PUT: modifying resources;
• HTTP Delete: Deletes a resource.

After completing the definition of two core concepts of resources and connectors, we have been able to outline the basic ideas of rest-style programming:

1. Abstract and define resources in the system;
2. Use a restful URI to bind the request to the resource;
3. Use HTTP requests to manipulate resources;

Also use the order system mentioned above for example, please see the following example:

    <!-- search for goods in the category of clothing information  -       get/rest/product http/1.1      Host:www.coolfancy.com            producttype Costume  

    <!-- query for order information with ID 1  -       get/rest/order/1 http/1.1      Host:www.coolfancy.com  

    <!-- Delete cargo information with ID 1  -       delet/rest/product/1 http/1.1      Host:www.coolfancy.com  

    <!-- Create an order information  -       post/rest/order http/1.1      Host:www.coolfancy.com            field1 value1      field2 value2      ...  

Simply put, the URI plus HTTP method forms the core rule of rest processing data: The URI determines the object of the operation, and the HTTP method determines how it is manipulated.

Unlike traditional ways of working with data, if you do not use rest, the objects and operations of the operation will be mixed in the URL design, just as Dr. Roy T. Fielding, who first presented the rest concept, said: "Rest allows us to design the system through a URL." In fact, Roy was also the main designer of the Web protocol, and it was with his participation that he completed the formulation of the HTTP1.1 specification.

At another point of view, rest emphasizes the concept of resources (data), where all operations are carried out around a specific resource, leaving the resources, and rest loses the meaning of existence. At this point, the ideas that rest advocates are similar to the popular Ajax programming styles.

Ajax emphasizes data and presentation separation, background applications are dedicated to production data, and the foreground uses scripts to display data. There is no built-in support for the organization of data and the transfer of Ajax. While rest emphasizes binding requests to resources through URIs, if you combine rest with Ajax technology, you can create an effective complement, and we might as well extend the programming ideas mentioned above, and still take the order information with ID 1 as an example:

1. Ajax initiation Request: HTTP://WWW.COOLFANCY.COM/REST/ORDER/1;
2. Bind the request to the background entity through a restful URI design;
3. The background entity returns the Json/xml data containing the product information;
4. The foreground uses a script to display the data.

We use spring MVC to implement the process described above, and as a mainstream MVC product, Spring MVC naturally supports the rest programming style, so using spring MVC to build restful applications will become surprisingly simple.

Spring MVC uses special annotations to decorate handler objects, allowing handler to handle rest-style requests, and let's look at a few examples:

/*** Get order information by ID value * *@paramID *@return */@ResponseBody @requestmapping (value= "/order/${id}", method =requestmethod.get) PublicOrderEntity GetOrder (@PathVariableintID) {returnordermanager.get (ID);}/*** Check cargo information by type * *@paramID *@return */@ResponseBody @requestmapping (value= "/product", method =requestmethod.get) PublicList<productentity>getproductbytype (String type) {returnProductmanager.querybytype (type);}/*** Create order information * *@paramID *@return */@RequestMapping (Value= "/order", method =requestmethod.post) Public voidCreateorder (orderentity entity) {ordermanager.create (entity);}/*** Change Order information * *@paramID *@return */@RequestMapping (Value= "/order/${id}", method =requestmethod.put) PublicOrderEntity UpdateOrder (@PathVariableintID, orderentity entity) {    returnordermanager.update (entity);}/*** Delete Order information for the specified ID value * *@paramID *@return */@RequestMapping (Value= "/order/${id}", method =requestmethod.delete) Public voidDeleteorder (@PathVariableintID) {ordermanager.delete (id);}

The example above shows how simple it is to write a restful application using spring MVC.

It is important to note that rest requires the identity of the resource to be constant, that is, for a particular resource, the ID of the resource cannot be changed, regardless of the operation on the resource. This restriction is added to ensure the consistency of the URI. Imagine that if an operation changes the identity of a resource during processing, then to ensure the integrity of the rules, we have to pay an extra price to synchronize these changes in other processes, which is unacceptable in rest.

On the other hand, rest requires that all operations on resources be stateless, and URIs are the only way to determine resources. If we incorporate state data into the process of data processing, the URI for the same resource will be two semantic, which will run counter to the rest definition.

Build restful web Apps with spring MVC