Hypermedia in a restful application

What the hell is hypermedia?!

If you are fortunate enough to have heard of the rest architecture style, you may also hear that some people think that a unified interface is the most important constraint, especially in terms of how the interface can be invoked to restrict resources. What you don't realize, though, is that there's a lot more to the unified interface. In particular, a child constraint that is clumsily dubbed the name "Hypermedia is the application state engine (hypermedia as the engine of application)", which can be considered the most important constraint of rest, In a sense it single-handedly shaped most of the "shapes" of the restful systems we know well.

Defined

Unfortunately, rest papers do not unfold on this constraint, except for its name and description of its actual application:

Therefore, the model application is an engine that migrates from one state to the next, and the migration is done by checking and selecting the optional state in the current presentation set.

Although it gives us a useful description, it does not, in my view, help us really understand the scope of the constraint itself, what the constraints really allow, and what is not allowed. And then it's worth noting that we can get some information out of the constraints on our own names.

"Application state" refers to a state that determines the "location" of the user in the process of completing a task. For example, when doing a personal banking business, is the user browsing the account balance, filling out an accounts payment form, or ordering a new check? Each of them is a different application state. Some people mistakenly believe that "state" refers to the state of the resource, in which case the resource refers to the account balance or the recent payment list. However, the application state and resource state are different.

The application state is also referred to as "session state", which is the state of rest's "stateless" constraint, which requires the client to maintain state alone. Conversely, if you use remote session technology such as VNC or Windows Remote Desktop, the application state is completely saved on the server.

Ted Nelson created the term "hypermedia" in 1962, the "hypertext" generalization he invented. Given that hypertext produces an internally interconnected text document, Hypermedia extends its scope to any form of media. Of course, the key point of both is that we can embed the link in the content used.

Constraint combat

REST began 2003/2004 years to gain some focus on internet service developers--at least, the developers actually dubbed their services "rest"--most notably two high-profile, self-styled "rest APIs": Flickr and Amazon. Interestingly, two services also provide soap based interfaces, but these two soap APIs do not show more use than the REST API. In the end, the rest community embraced these services and used them as a tool to further explain the value and glamour of using rest styles on the web. Unfortunately, there is a problem with these APIs: they are not entirely restful because they ignore (at least) a rest constraint. In fact, the Flickr API (and Amazon, del.icio.us, and so on) is a lot more problematic than we've discussed here, and we're focused only on issues that are related to hypermedia.

Luckily, we don't need to spend too much time looking for these problems. Sample data returned with the "Flickr.contacts.getList" operation is an example that allows users to obtain their own list of contacts by using this action:

<contacts page="1" pages="1" perpage="1000" total="3">
<contact nsid="12037949629@N01" username="Eric" iconserver="1"
realname="Eric Costello"
friend="1" family="0" ignored="1" />
<contact nsid="12037949631@N01" username="neb" iconserver="1"
realname="Ben Cerveny"
friend="0" family="0" ignored="0" />
<contact nsid="41578656547@N01" username="cal_abc" iconserver="1"
realname="Cal Henderson"
friend="1" family="1" ignored="0" />
</contacts>

Here, the "Nsid" property contains a unique identifier that represents a single contact, in this case three of the contacts. But once the client has retrieved the document, what happens next? What if they want to get more information about Cal Henderson? By quickly checking the Flickr API documentation, you can find an operation called "Flickr.people.getInfo" that receives NSID as a parameter and returns more information about the contact that the Nsid string identifies. So in order to get more information about Cal, the URI we need to use in the HTTP getting message will be:

http://api.flickr.com/services/rest/?method=flickr.people.getinfo?auth_key=xxxx&user_id=41578656547@ N01 this is not hypermedia. A hypermedia solution uses a standardized identifier-a uri--rather than a private identifier for the web, which avoids the need for Flickr-specific knowledge for the client to navigate from the contact list document to the personal information document. If you use a standard identifier, the first document should be:<contacts page="1" pages="1" perpage="1000" total="3">
<contact nsid="http://api.flickr.com/services/rest/?method=flickr.people.getInfo?auth_key=xxxx&user_id=12037949629@N01" username="Eric" iconserver="1"
realname="Eric Costello"
friend="1" family="0" ignored="1" />
<contact nsid="http://api.flickr.com/services/rest/?method=flickr.people.getInfo?auth_key=xxxx&user_id=12037949631@N01" username="neb" iconserver="1"
realname="Ben Cerveny"
friend="0" family="0" ignored="0" />
<contact nsid="http://api.flickr.com/services/rest/?method=flickr.people.getInfo?auth_key=xxxx&user_id=41578656547@N01" username="cal_abc" iconserver="1"
realname="Cal Henderson"
friend="1" family="1" ignored="0" />
</contacts>