The main role belongs to hypermedia. Hypermedia is a term used to describe media that can be linked with each other in a non-linear way. My primary goal in this article is to present you the foundations of hypermedia: the concepts and thoughts of the favourite markup language and its communication protocol partner.

Hypertext Markup Language (HTML)

The purpose of HTML is to define a markup schema to the World Wide Web (WWW) project documents. HTML is the most important media document of WWW project.

The HTML allows the content to define links to another kind of medias. An image in a document for example is a link to another media. The most remarkable link is the hyperlink. Hyperlinks allows the user to navigate across the document and to others documents. All the media linked -or accessed- in a browser trough the Internet use the HTTP protocol, which we will talk below.

Hypertext Transfer Protocol (HTTP)

HTTP is a communication protocol to distribute hypermedia resources identified by an URL. It is the main Internet protocol that we, as developers, need to understand well. In summary, the protocol is designed to request and receive medias between client and server.

Communication is composed by an amount of information exchanged between emitter and receiver. Similar to the way people treat each other, communication needs to be cordial amidst computers too. For this purpose, the HTTP protocol defines a request and response header. The message header contains useful information to client and server. Through the information passed by the header, it establishes a content negotiation. This negotiation is based on content language, media types, document expiration and other stuff.

Request Methods

The HTTP protocol defines methods, also called “verbs”, to be used for request documents. These verbs are part of the content negotiation and they are passed at the header of the request message. The main methods that you should know are:

• GET: it requests an object from the server. By object I mean any entity that the server knows and the client wants to load.
• PUT: it writes an object to the server. This type of request might be called more than once without affecting its first result (and creating side effects). These requests carry an object identifier and it is used to change the object attributes.
• POST: it writes an object on the server too, but in a different way. Requests of this type might affect the server when called more than once. The main use of this type of requests is usually to create new object in the server.
• DELETE: it remove an object on the server.

The specifications evolution

In the beginning, the browser was just an interface to a vast and distributed library. The HTTP protocol only had one GET method before its specification. There was no need to change the information stored in the servers. When the first HTTP specification came in, it was more ambitious and defined a set of requests methods. With this methods it is possible to make explicit that a change is going to be performed at server.

Created after the HTTP specification, the first HTML specification was less ambitious. Picture a HTML without the <form> element! Even so, the HTTP methods were not left out. The anchors accepted a methods attribute to indicate the object allowed request methods. But only a few browsers supported this attribute, and it didn’t get too much attention. The current specification does not include the methods attribute anymore.

When the second specification of HTML was released the goal was not only to markup the document content. This specification raised HTML to an Internet Media Type. Users now are able to fill in and send form templates besides navigate and interact with documents.

In addition to an action attribute, which contains the destination URL, the <form> element allowed a method attribute that accepts the GET and POST verbs. According to the specification, the POST method must be used to change the application database or assign to a service.

The specifications mismatch

In the current specification, HTML supports links that perform GET requests and forms that perform GET orPOST requests. HTML doesn’t have any way to perform a PUT or DELETE request.

To understand the mismatch problem better, let me introduce a style that try to handle a good communication between requester and sender among HTTP.

Representational state transfer (REST)

Thanks to the ubiquity achieved by browsers, Internet applications are becoming increasingly common. “REST” is an architecture style that explains how applications should use the HTTP protocol and URLs to represent resources.

According to the REST approach, resources are identifiable objects in the server. Resources can be documents, images, videos, or other kinds of media. Any resource must have an identifier, in other words, any resource must have an URL. For example, an application to manage products can identify one product resource by the URL/products/59.

Through the HTTP request methods, the client can perform actions on the resources. Given the same application, requests sent with the methods GET, PUT and DELETE to the URL /producsts/59 must respectively show, change and destroy the product resource. So there is only one unique URL that can be used to address three different actions.

Representation is the last concept related to REST that I want to show. The server always transfers a representation of the resource. The request header can inform what representation formats are supported by the client. Thus, the same resource might by transferred as HTML, JSON, XML, and others.

Ruby on Rails, a framework used to develop web applications, provides features to assist the implementation of REST resources. Rails Routing guide is a good resource to learn how the framework handles REST style. The guide defines how to assign URLs and MVC controller-actions based on resources.

There are many great articles about the REST style. One of my favourite articles is the How I Explained REST to My Wife.

The problem and future solutions

As HTTP does not support PUT or DELETE, we are restricted to implement REST for building a well-designed application with HTML only. In other words, to be fully compliant with REST style a page should exclusively either view or create new resources. It is not possible to destroy or change resources with all sorts of HTTP verbs because HTML do not allow them.

There were many debates about this compatibility issue. Of course, there are many solutions proposed. The most notorious being the HTML Form HTTP Extensions that changes the form methods attribute to accept the majority of HTTP 1.1 request methods. This way, it is possible to trigger a DELETE request through a form. The proposal remains as an unofficial draft and is not supported by any browser.

Solutions

According to the HTML specification, links are connections between two resources. As explained soon, the hyperlinks allows the user to navigate in the document content or get another resource following an URL. Nothing more than that. In the HTML, the hyperlink are represented by a <a> tag with href attribute.

All kind of link always perform a GET request. This category must not include side effects at the server. Request that causes side effects, like create, change or delete an object, must be performed by a <form> usingPOST method.

Using forms to handle REST

The HTML specification didn’t evolve the forms to be better in performing more types of requests. But regardless, the REST style is supported by the Ruby on Rails framework and evangelised by the community. Let’s see how this is possible. Rack is a dependency of Ruby on Rails that acts as a web application interface base. Rack allows that a form send a normal POST in the method attribute and informs the correct method in a field named_method. In fact, it fakes a request method to the application without really changing the request method performed by HTTP protocol. The form below is parsed as an intention to destroy the resource identified by/products/59:

<form method=”post” action=”products/59">
 <input type=”hidden” name=”_method” value=”delete”>
 <button>Delete this product</button>
</form>

Just so you know, this is not the best way to write code in your Ruby on Rails project view templates. It is better to use the Form Helpers to make the dirty job and include the hidden field to you.

Other full-stack web application frameworks that implement this solution includes the PHP Laravel frameworksupports the same _method field.

The advantages and flexibility of this solution is to be able to use the same URL to handle a resource using just different request methods. And thanks to REST content-negotiation policy the same URL can return a HTML or JSON representation of the resource based on the request header.

Resource destruction

At administration areas, it is very common to find out resources in a table with a <a> to perform deletions. This is wrong for several reasons. Hyperlinks are designed to navigate to an object, and it shouldn’t change anything. Remember that in an archaic past, there were programs that followed all page links to cache the content and speed up navigation. In this case, the resources may end up being deleted just by following links.

The very least you must do is change these <a> to a submit button wrapped in a form, even if you’re not pursuing REST compliance. An argument against this approach is the burden to stylise a <button> tag.

There is also a crude alternative that uses JavaScript to change the <a> when clicked to submit a form. Ruby on Rails does exactly this with the help of jquery_ujs script included in jquery-rails gem. The script looks for elements with data-method attributes as shown below:

<a href=”products/59" data-method=”delete” rel=”nofollow”>Remove</a>

The rel attribute is designed to explain the relation of the source and destination. The value nofollow is a search engine pattern that cordially marks the link to not be followed.

An important detail is that through out this approach, if the JavaScript is prevented from running in the browser, the user will perform a normal GET and according to REST end up at a representation of the resource. The solution is to include a form at this representation page that allows the destruction of the resource. This feature is often overlooked and deleting resource is only possible over JavaScript.

Author’s note

The REST concepts are very interesting and I hope that soon we can adopt it natively on HTML. It would be great and certainly a required evolution of the specification.

Do not forget that an user clicking a link cannot cause side effects in your application. Use and abuse forms. Moreover, make the back-end of your application following the REST style. Choose a good framework and go forward. I hope you enjoyed this reading.