Rest on ASP. net mvc (and future)

 

See also: <Enterprise rest = customize, invent and standardize media types>

 

MVC and rest are two different world views. the former is more about modeling behavior, while the latter emphasizes data (state and state change ). the former provides guidance on internal implementation,
Separating the program structure into a model, view and controller. The latter provides an external view of the system: a group of system changes induced by hypermedia.

 

MVC and rest describe the world in two different dimensions, instead of two opposite views at the same latitude, therefore, it is possible to develop rest-compliant applications based on a large number of existing MVC frameworks.
But the tool is a reflection of the world outlook. The support of the MVC Framework for rest is not so direct. When we use the MVC framework to develop rest applications, we should avoid possible conflicts,
Focus on the rest-compliant features. Let's take a look at ASP. net mvc's support for rest.

 

Client-server

 

The principle behind customer-server constraints is to separate concerns, such as user interfaces and data storage. For the web, the most important thing is that the separation of concerns allows components to evolve independently.

 

ASP. net mvc is a server-side development framework. It has no contribution or negligence in this constraint. It generates HTML code that complies with the standard and has no special requirements on the client's capabilities.

 

Stateless

 

ASP. net mvc provides the session concept. It can be understood as the state of a specific client saved on the server side. Using this feature will violate the stateless constraints,
This may cause a reduction in scalability. To ensure that this constraint is not accidentally destroyed, you can disable the session through a series of configurations, such as adding <sessionstate in Web. config
Mode = "off"/>, or use code to configure a single controller:

 

[Sessionstate (sessionstatebehavior. disabled)] <br/> public class coolcontroller: controller {<br/> Public actionresult index () {<br/> Object o = session ["key"]; // causes an exception. <br/>}< br/>}

 

ASP. net mvc also provides support for cookies, and cookies are a feature that violates rest constraints. "cookies are defined as being appended to any future requests,
For a specific set of resource identifiers, cookies are usually associated with a complete site, rather than the specific application status in the browser (the group of States currently presented) associated.
In addition, it allows data to be transmitted without fully indicating its semantics. ". ASP. NET provides cookieless options so that we can disable cookie support.

 

Cacheable

 

ASP. net mvc provides an actionfilter called outputcache to support caching. outputcache is a little too powerful,
It not only supports caching between the client and the server, but also supports caching between the application code on the server and the database. You can also set the cache location,
For example, it is placed in the client browser (that is, adding the standard HTTP Cache Control headers in response) or on the server. Besides supporting the whole page cache,
It also supports partial page caching (I understand that it can only be cached on the server)

 

Public class homecontroller: controller <br/>{< br/> [outputcache (duration = 10, varybyparam = "NONE")] <br/> Public actionresult index () <br/>{< br/> return view (); <br/>}< br/>}

 

When a large number of independent clients request the same content, such as the same image or video, the server cache is more effective than the Client Cache. However, there is a component called reverse proxy to address this problem,
This responsibility can be removed from the server application code and turned into a part of the Web infrastructure, provided that the server needs to set standard HTTP Cache Control
Headers. In this case, this type of cache is usually called shared cache. We will discuss this issue later when talking about layering.

 

Therefore, for rest applications, I personally feel that the application client cache is preferred, so that the existing web infrastructure can be used to the greatest extent possible.

 

Layered System

 

Similar to client-server constraints, ASP. net mvc does not work here. However, some features may make it impossible to fully play the role of those intermediate layers.

 

For example, the impact of Session on Load balancer. if the service end stores sessionin the memory of w3wp.exe, load
Balancer will not be able to configure the session sticky policy, so it cannot achieve real load balancing

 

For example, the server cache will make the reverse proxy ineffective.

 

Code on demand (optional)

 

The Mobile Code style supported by native on the. NET platform is Silverlight, but ASP. net mvc does not provide any support for this,
For example, there is no Silverlight-based view engine.

 

For JavaScript, ASP. net mvc provides limited support, but provides some auxiliary code that can generate some Ajax call code in the view,
Such as ajaxhelper. actionlink and ajaxhelper. beginform.

 

The server also provides a representation called jsonresult, which can be easily manipulated by the client JavaScript.
However, this is more about the support for multiple representation types, which will be mentioned later.

 

Uniform Interface

 

"The core feature that distinguishes the rest architecture style from other network-based Architecture styles is that it emphasizes that there must be a unified interface between components. By applying universal software engineering principles on component interfaces,
The overall system architecture is simplified, and the interaction visibility is also improved. implementations are decoupled from the services they provide, which promotes independent evolution. however, the cost is that unified interfaces reduce the efficiency,
The rest interface is designed to efficiently transfer large particles because information is transferred in a standardized manner, rather than in an application-specific form.
Ultra-media data of degree, and optimized for common web situations, but this also leads to the interface is not optimal for other forms of architecture Interaction

 

To obtain a unified interface, multiple architecture constraints are required to guide the behavior of components. Rest is defined by four interface constraints: Resource Identification
Resources ).
Representations), Self-descriptive messages, and hypermedia
As the engine of application state) "-- from <rest_cn
>

 

Identification of resources

 

Resource identification or identification is a conceptual or semantic abstraction that clearly distinguishes the physical implementation of resources and the expression of resources returned to the client. it is the responsibility of developers to define an identifier for a resource,
ASP. net mvc does not help. ASP. net mvc. It only helps to map resource identifiers to resource implementation (implemented through urlroutingmodule ).
In other words, whether a URL is restful does not mean whether it looks clean and has no parameters through superb routing technology, but whether it is a permanent concept,
Whether the underlying implementation can be changed without any adjustment.

 

Multiple standard HTTP operations, such as post, put, get, and delete, can be performed on the same URL,
A good route ing should be able to map different HTTP operations to different objects or methods. ASP. net mvc provides this support:

 

Routes. maproute (<br/> "default", <br/> "{controller}/{action}/{ID}", <br/> New {controller = "home ", action = "Index", id = ""} <br/>); <br/> [acceptverbs ("Post")] <br/> [actionname ("Index")] <br/> Public actionresult create () <br/>{< br/>}< br/> [acceptverbs ("get")] <br/> [actionname ("Index")] <br/> Public actionresult read (guid ID) <br/>{< br/>}< br/> [acceptverbs ("put")] <br/> [actionname ("Index")] <br/> Public actionresult Update (guid ID) <br/>{< br/>}< br/> [acceptverbs ("delete")] <br/> [actionname ("Index")] <br/> Public actionresult Delete (guid ID) <br/>{< br/>}

 

 

Manipulation of resources through these representations

 

In ASP. net mvc, resource representation is expressed by the concept of actionresult. For example, HTML is generated.
Viewresult, produce JSON jsonresult, and generate JavaScript javascriptresult.
When we need to define our own media type, we can extend the actionresult.

 

Self-descriptive messages

 

Generally speaking, this refers to the access to various information in the HTTP header. ASP. NET
MVC supports metadata through the httprequest and httpresponse classes. Of course, parsing the data, understanding its meaning, and following its instructions,
It is the responsibility of developers to set appropriate responses.

 

Hypermedia as the engine of application state

 

Finally, the core features of rest are reached. ASP. net mvc does not consciously provide support. It is not surprising that, first of all, MVC prefers an RPC design instead of rest,
Second, this constraint is implemented by developers rather than magic frameworks.

 

HTML is the only hypermedia supported by ASP. net mvc. In a class called htmlhelper, a large number of methods are provided to conveniently generate valid HTML,
And the most important link to other resources, such as htmlhelper. actionlink (...)

 

Link to other resources is the core of hypermedia. It can be used in non-HTML media types, such as atom feed. ASP. NET.
MVC provides urlhelper to generate various links.

 

 

ASP. net mvc future

 

ASP. net mvc future contains a set of features that ASP. net mvc team deems may be added to ASP. net mvc official release in the future.
In the current version (ASP. net mvc 3 RTM), ASP. net mvc future adds more rest support.

 

More super media types, such as atom feed
: Atomentryactionresult and atomfeedactionresult provide support for atom.
In fact, these two classes are easy to set content-type. The core functions are delegated to syndicationfeed and syndicationitem.
The latter is provided by. NET Framework.

 

JSON and XML model Binder
: JSON and XML loads in requests can be directly bound to parameters defined in the form of objects for action.

 

Popular "Restful" Routes
: This is implemented through routecollectionextensions and resourcecontrollerfactory.
For example, the former can help you establish the following routes:

 

/// A controllername of "books" and a routesuffix of "{ID}" Will <br/> // result in the following routes being registered for the Controller: <br/> ///~ /Books /,~ /Books/{ID} to the resource, <br/> ///~ /Books/createform to the createform controller action, <br/> ///~ /Books/{ID}/editform to the editform controller action <br/> Public static void mapresourceroute (this routecollection routes, string controllername, string routesuffix) {<br/> routes. mapresourceroute (controllername, null, routesuffix, null); <br/>}

 

However, a feature that many developers expect is to route based on the accept value in the httprequest header, whether it is ASP. net mvc or future,
Are not provided. For example, the following statement is not supported currently:

 

[Acceptformat ("application/atom + XML")] <br/> Public actionresult read () <br/>{< br/> return New atomfeedactionresult (...); <br/>}< br/>

 

See also: <Enterprise rest = customize, invent and standardize media types>