How does this Webmachine thing work, anyway?

This page describes the basic mechanics of Webmachine from the point of view of a single incoming HTTP Request, documenting the behavior of Webmachine through to the HTTP Response.

(This is a bit different from what you might get with a “Web Framework” as we’re not going to talk about MVC, ORMs, or anything else about the rest of the shape of your application. We believe that you know better than we do how to structure your own app – Webmachine’s job is to help you make sure that your app’s presence on the Web is well-behaved and well-structured.)

When a request is initially received by Webmachine it is handled by the dispatcher. If the dispatcher does not find a matching resource then it will immediately respond with a 404 Not Found. If a match is found then a request data record is created and the matching resource is kicked off via its init/1function.

The resource then flows through the decision core, which is effectively just running the request through the HTTP flowchart. At each decision point (diamond) in the diagram, Webmachine will determine which path to follow. In some cases it can determine the path purely from the request data – for instance, the path from decision C3depends purely on whether the client sent an Acceptheader. In many cases, however, the decision is application-specific – the path from B10depends on the value the resource module returns from allowed_methods.Eventually the chosen path will terminate at one of the rectangles on the diagram. At that point Webmachine will send an appropriate HTTP response, with the headers and body dependent on the path through the diagram and the values returned by the resource’s functions.

Most of the time you don’t need to worry about this big diagram, though – just define the resource functions relevant to your app and Webmachine will do the rest. A good understanding of this central mechanism in Webmachine is most useful when debugging your resources.

From the way that webmachine’s decision core works, it follows that Webmachine’s HTTP behavior is transactional. Each HTTP Request is fully received, and the resulting HTTP Response is then fully constructed before being returned. This means that while Webmachine is suitable for a great many Web applications it is not a good fit for an application that will gradually or continuously stream responses back to clients inside the context of a single HTTP Request.

A useful way to build Webmachine applications is often just to write a single function such as to_htmlto provide the most basic of stubs; when that function exists (or any other returned by content_types_provided) you can produce 200 OK responses. After that, you can easily extend your application’s Web behavior simply by filling in the other resource functions as desired.