How to maintain application status

How to maintain application status

When reading articles about rest, you often get this advice-saving the application status on the client. But what is "Application Status "? How should I save these statuses on the client? This section describes best practices for saving the application status.

Problem description

You want to know how to manage the restful web service status, so that you do not need to rely on sessions in the server memory.

Solution

Encode the application status to the URI and include these URIs in the representation through links (See Chapter 5th ). Allow the client to use these URIs to interact with resources. If the status is too large or cannot be transmitted over the network for security or privacy reasons, you can store the application status in persistent storage (such as databases or file systems, and encode the reference of its status in Uri.

Problem Discussion

Consider a simplified vehicle insurance application, which involves two steps. Step 1: The client submits a request with driver and vehicle details, and the server returns a valid price for one week. Step 2: the client submits an insurance purchase request. In this example, the application state is the quotation. The server must know the quotation returned from the first step, based on which the policy in the second request can be provided.

The application status is the status that the server needs to maintain between each request of each client. Maintaining this state on the client does not mean serializing session states to URI or HTML forms as Web frameworks such as ASP. NET and assumerver faces do.

Because HTTP is a stateless protocol, each request is independent from the previous request. However, interactive applications usually require the client to follow the specific sequence during execution. This requires the server to temporarily store the current location of each client in the step sequence outside the protocol. The trick here is to manage the status so that you can strike a balance between reliability, network performance, and scalability.

The link in the resource expression is the best place to keep the application state, as shown below:

# Request

Post/quotegen HTTP/1.1

HOST: www.example.org

Content-Type: Application/X-WWW-form-urlencoded

Fname =... & lname = ...&..

# Response

HTTP/1.1 200 OK

Content-Type: Application/XML; charset = UTF-8

<Quotexmlns: Atom = "http://www.w3.org/2005/Atom">

<Driver>

...

</Driver>

<Vehicle>

...

</Vehicle>

<Offer>

...

<Valid-until> 2009-10-02 </valid-until>

<ATOM: linkhref = "http://www.example.org/quotes/buy? Quote = abc1234"

Rel = "http://www.example.org/rels/quotes/buy"/> internal

</Offer>

</Html>

Publish a link containing the application status

In this example, the server saves the quotation in the data storage and encodes the primary key in the URI. When the client uses this URI to initiate a request for insurance, the server can use this primary key to restore the application status.

You should select persistent storage like a database or file system to save the application status. Using non-persistent storage such as cache or memory sessions will reduce the reliability of web services. For example, the status may be lost when the server is restarted, and the non-persistent storage solution will also reduce the scalability of the server.

If the amount of data required for the quotation is small, the server can encode the status in the URI, as shown in the code later.

When the application status is saved in the database, Use Database Replication so that all server instances can access these statuses. If the application status is not permanent, you may need to clear the status in some places.

# Request

GET/quotegen? Fname =... & lname =... & HTTP/1.1

HOST: www.example.org

# Response

HTTP/1.1 200 OK

Content-Type: Application/XML; charset = UTF-8

<Quotexmlns: Atom = "http://www.w3.org/2005/Atom">

<Driver>

...

</Driver>

<Vehicle>

...

</Vehicle>

<Offer>

...

<Valid-until> 2009-08-02 </valid-until>

<ATOM: linkhref = "http://www.example.org/quotes/buy? Fname =... & lname = ...&..."

Rel = "http://www.example.org/quotes/buy"/>

</Offer>

</Html>

Because the client needs to send the above data back in each request, encoding the application status in the link will reduce network performance. However, this can improve scalability because the server does not need to save any data or improve reliability, because the server does not need to use replication. You can combine the preceding two methods to manage application states based on the number of specific use cases and statuses to maintain a balance between network performance, scalability, and reliability.

 

This article is excerpted from the book restful Web Services cookbook Chinese version.

Book details: http://blog.csdn.net/broadview2006/article/details/6826999