3.5 KiB
REST, Hypermedia & HATEOAS
You keep using that word "REST". I do not think it means what you think it means.
— Mike Amundsen, REST fest 2012 keynote.
First off, the disclaimer. The name "Django REST framework" was chosen simply to sure the project would be easily found by developers. Throughout the documentation we try to use the more simple and technically correct terminology of "Web APIs".
If you are serious about designing a Hypermedia APIs, you should look to resources outside of this documentation to help inform your design choices.
The following fall into the "required reading" category.
- Roy Fielding's dissertation - Architectural Styles and the Design of Network-based Software Architectures.
- Roy Fielding's "REST APIs must be hypertext-driven" blog post.
- Leonard Richardson & Sam Ruby's RESTful Web Services.
- Mike Amundsen's Building Hypermedia APIs with HTML5 and Node.
- Steve Klabnik's Designing Hypermedia APIs.
- The Richardson Maturity Model.
For a more thorough background, check out Klabnik's Hypermedia API reading list.
Building Hypermedia APIs with REST framework
REST framework is an agnostic Web API toolkit. It does help guide you towards building well-connected APIs, and makes it easy to design appropriate media types, but it does not strictly enforce any particular design style.
What REST framework provides.
It is self evident that REST framework makes it possible to build Hypermedia APIs. The browsable API that it offers is built on HTML - the hypermedia language of the web.
REST framework also includes serialization and parser/renderer components that make it easy to build appropriate media types, hyperlinked relations for building well-connected systems, and great support for content negotiation.
What REST framework doesn't provide.
What REST framework doesn't do is give you is machine readable hypermedia formats such as HAL, Collection+JSON or HTML microformats by default, or the ability to auto-magically create fully HATEOAS style APIs that include hypermedia-based form descriptions and semantically labelled hyperlinks. Doing so would involve making opinionated choices about API design that should really remain outside of the framework's scope.