Enterprise rest = customize, invent and standardize media types

Document directory

• URL template considered harmful
• References

 

One of the most confusing issues about rest is:
In the rest application of machine-to-machine,
How can the Client follow the hypertext returned by the server without any prior knowledge to adapt the application logic?

The answer is impossible.
. The client must know enough in advance
Hypertext returned by the server
In order to follow the instructions below to proceed with the logic
.
That follows
What are the differences between soap and WSDL?
? The answer is:
Rest requirements
"Sufficient knowledge
"Far weaker
WSDL constraints on Service Interface Definition
,
Its flexibility is higher
WSDL. after all
, Rest architecture style focuses on a long life cycle
, Constantly evolving
, Applications across organizational boundaries
. Can be used to meet
Hateoas
The weapon of rest constraints is
Media type:Expand existing
Media type, new
Media type,
And standardized within the appropriate scope

 

Let's look at two examples.
.

 

Web success is not so much
HTTP success
It is better to say
HTML success
,
Or
Text/html
Media type successful
.
HTML defines a limited set
,
Standardized
, Tags for specific fields
.
All
The HTML client can understand and render it based on its own capabilities.
Any valid
Html. From the full-featured
Chrome/Firefox
/Safari/IE, to only display text
Lynx, to various browsers such as mobile phones in resource-constrained Environments
, Can be colorful
WEB presentation to end users
And guide them to the next interaction

Most often used
The success stories of machine-to-machine rest applications are:
RSS/atom. The family standard defines the new
Media
Type, application/RSS + XML
, Application/atom + XML
. Unexpected
, This group
Media
Types defines a limited set
, Standardized
, Tags for specific fields
. Every
Both the RSS and atom client applications can
Application/RSS
(Atom) + XML
To traverse every resource of interest.
These clients understand every
Tags defined by RSS/atom
. The server can freely change the new resource
Uri/URL template without worrying about cracking existing
Client, because
The client does not rely on preset
The URL template depends on only one
Root statement
, And standard
Link relations

 

Back to our questions
.
Rest requirements
"Sufficient knowledge
"To what extent?
,
So that the client can understand the clues provided by the server.
Does not mean that the coupling is too tight, so that the server and client cannot evolve independently.
?
Observe the two examples above
They share the following common features:
:

1.Response is
Well-formed
, Which can be parsed by the client

. This is nonsense.
,
Besides
AI applications
Most network applications must have clearly defined protocols.
.
But this means
The format of data exchange between the client and the server must be clearly defined in rest applications.

2.Response contains the current context
(
Or Resource
) Related information
But for us, it is more important to include clues to access other resources.

.
Yes
It is the most basic
, The most common
Link
. Weak enough
Whether the semantics is clear enough that the client can understand every
Link.
Link and know how to access it
? Let's take a look.
What semantics can link carry?
(From
Http://www.ietf.org/rfc/rfc5988.txt ):

  Link           = "Link" ":" #link-value  link-value     = "<" URI-Reference ">" *( ";" link-param )  link-param     = ( ( "rel" "=" relation-types )                 | ( "anchor" "=" <"> URI-Reference <"> )                 | ( "rev" "=" relation-types )                 | ( "hreflang" "=" Language-Tag )                 | ( "media" "=" ( MediaDesc | ( <"> MediaDesc <"> ) ) )                 | ( "title" "=" quoted-string )                 | ( "title*" "=" ext-value )                 | ( "type" "=" ( media-type | quoted-mt ) )                 | ( link-extension ) )  link-extension = ( parmname [ "=" ( ptoken | quoted-string ) ] )                 | ( ext-name-star "=" ext-value )  ext-name-star  = parmname "*" ; reserved for RFC2231-profiled                                ; extensions.  Whitespace NOT                                ; allowed in between.  ptoken         = 1*ptokenchar  ptokenchar     = "!" | "#" | "$" | "%" | "&" | "'" | "("                 | ")" | "*" | "+" | "-" | "." | "/" | DIGIT                 | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA                 | "[" | "]" | "^" | "_" | "`" | "{" | "|"                 | "}" | "~"  media-type     = type-name "/" subtype-name  quoted-mt      = <"> media-type <">  relation-types = relation-type                 | <"> relation-type *( 1*SP relation-type ) <">  relation-type  = reg-rel-type | ext-rel-type  reg-rel-type   = LOALPHA *( LOALPHA | DIGIT | "." | "-" )  ext-rel-type   = URI

 

Here we will focus on
REL

And
Media-type
Attribute

 

In
In atom (http://www.ietf.org/rfc/rfc4287.txt)
, Defined by default
5 types
Link
Relations, which are
Alternate, related, self, enclosure and
Via. standards give them clear Semantics
For example
Alternate
Link directs to the standby version of the current resource.
The client can understand each
Link Description
, Automatically or guide the user to complete subsequent operations
.
How to complete? It involves
Media-type
. For example, if
Media-type defines
Audio/MP4, the client can display the playback option or automatically play or simply ignore
.

 

Here
Link and
Media-type and other attributes help form a recursive process
. From
Link
, Know it
Media-type
Media-type,
This is what we can understand.
The semantics of each element defined by media-type
), We can get this
The resources that link points
A representation of media-type
, Including other available
Link and
Media-type to keep this process going
Until the client thinks it is okay or the server returns no other content
Link Description
.

 

However, the initial
Media-type and
Link
Relations are always limited.
, How do we deal with existing
Media-type cannot express semantics? This is
HTML and
The third element in the RSS/atom example

 

3.Define domain-related
Media-type
How does the. html problem domain express various display effects?
, RSS/atom is how to publish information
. Media-type and
Link
Relations and so on are all scalable
What we need to do is to define extensions for our applications in specific fields.
If the existing standardized elements are insufficient
. Here is a problem
That is
Scope of rest applications
. If our application is oriented
Internet
For countless unknown client applications
, Which means we must standardize our extended
Media-type, or at least make it widely accepted
.
For internal enterprises
Rest architecture applications
We are also faced with standardization issues.
, But the range may be smaller.
At least, it must be accepted by the enterprise.
Media-type

 

We have seen the well-defined
How media-type helps customer applications
Server
Response without tightly coupled with the implementation of the server
. We need an enterprise development example to verify our understanding.
.
For example, you need to develop an application that shares user information between different applications in an enterprise.
Including permission information
,
Operations that can be performed currently
, Accessible applications
And shared between applications
Preference settings
. We can define
Application/vnd.tw. Account + XML
Of
Media-type can have the following fragments:

<Account> <br/> <preference> <br/> <LINK rel = "preference" media-type = "application/vnd.tw. account. preference + XML "href =" http: // xxx/preference "mce_href =" http: // xxx/preference "/> <br/> <LINK rel =" edit "media-type =" text/html "href =" http: // xxx/preference/editform "mce_href =" http: // xxx/preference/editform "> <br/> </preference> <br/> <subscribed-services> <br/> <subscribed-service> <br/> <name> taxes </Name> <br/> <LINK rel = "subscribe" media-type = "text/html" href = "http://taxes.xxx.com" mce_href = "http://taxes.xxx.com"/> <br/> </subscribed-service> <br/> <Name> Audit </Name> <br/> <LINK rel = "subscribe "media-type =" text/html "href =" http://audit.xxx.com "mce_href =" http://audit.xxx.com "/> <br/> </subscribed-service> <br/> </subscribed- services> <br/> <contacts> <br/> <contact> <br/> <Name> Tom </Name> <br/> <LINK rel = "Contact" Media -type = "application/xfn + XML" href = "http://account.xxx.com/tom" mce_href = "http://account.xxx.com/tom"/> <br/> </contact> <br/> </contacts> <br /> </account> <br/>In this way, whether the Interactive Client is like a browser or an automated background application
.
Follow
Media instructions to perform operations that you are interested in

 

URL template considered harmful

If these are all implemented
You can have an inference:
URL
The template is not mandatory or even harmful.
. It limits Server Changes
.
Customer applications should always follow
Start with root Resource
, In a specific
Parse other
Uri, giving the Service Program Flexibility instead of following
Estimate the URL template based on previous knowledge.
.

Xu Hao who has done many projects with rest
URL

Template has the same view: "url template is harmful to me. It is an implicit server and client convention. In addition, most URLs
Template is used to express the state
Transfer URL, such as/XXX/approve, makes the client have to understand the details of server status transfer, which is a bigger problem in my opinion. This makes the customer
The coupling between the client and the server becomes closer, and this style strongly encourages the server to maintain state consistency through the client"

Many rest-related articles put a lot of space
HTTP, such
HTTP
Verbs post/get/Put/delete, HTTP Status Code, etc.
, And
Media
There are not many types of Ink
. Xu Hao has mentioned the custom media type many times in the community. There may not be many rest applications that I don't quite understand at the time. Now more and more people are aware that there are more extensions and standardization.
Media type can be used more
Potential of rest

 

References

Http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Especially later discussions

Http://www.iana.org/assignments/link-relations/link-relations.xml

Http://microformats.org/wiki/existing-rel-values

Http://www.w3.org/TR/html401/types.html#type-links