diff options
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/browsable-api.md | 9 | ||||
| -rw-r--r-- | docs/topics/browser-enhancements.md | 64 | ||||
| -rw-r--r-- | docs/topics/browserhacks.md | 43 | ||||
| -rw-r--r-- | docs/topics/credits.md | 18 | ||||
| -rw-r--r-- | docs/topics/csrf.md | 4 | ||||
| -rw-r--r-- | docs/topics/migration.md | 8 | ||||
| -rw-r--r-- | docs/topics/release-notes.md (renamed from docs/topics/changelog.md) | 13 | ||||
| -rw-r--r-- | docs/topics/rest-framework-2-announcement.md | 100 | ||||
| -rw-r--r-- | docs/topics/rest-hypermedia-hateoas.md | 12 |
9 files changed, 213 insertions, 58 deletions
diff --git a/docs/topics/browsable-api.md b/docs/topics/browsable-api.md index ed27752f..9fe82e69 100644 --- a/docs/topics/browsable-api.md +++ b/docs/topics/browsable-api.md @@ -1,4 +1,9 @@ -# Working with the Browsable API +# The Browsable API + +> It is a profoundly erroneous truism... that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them. +> +> — [Alfred North Whitehead][cite], An Introduction to Mathematics (1911) + API may stand for Application *Programming* Interface, but humans have to be able to read the APIs, too; someone has to do the programming. Django REST Framework supports generating human-friendly HTML output for each resource when the `HTML` format is requested. These pages allow for easy browsing of resources, as well as forms for submitting data to the resources using `POST`, `PUT`, and `DELETE`. @@ -85,7 +90,7 @@ The context that's available to the template: For more advanced customization, such as not having a Bootstrap basis or tighter integration with the rest of your site, you can simply choose not to have `api.html` extend `base.html`. Then the page content and capabilities are entirely up to you. - +[cite]: http://en.wikiquote.org/wiki/Alfred_North_Whitehead [drfreverse]: ../api-guide/reverse.md [ffjsonview]: https://addons.mozilla.org/en-US/firefox/addon/jsonview/ [chromejsonview]: https://chrome.google.com/webstore/detail/chklaanhfefbnpoihckbnefhakgolnmc diff --git a/docs/topics/browser-enhancements.md b/docs/topics/browser-enhancements.md new file mode 100644 index 00000000..6a11f0fa --- /dev/null +++ b/docs/topics/browser-enhancements.md @@ -0,0 +1,64 @@ +# Browser enhancements + +> "There are two noncontroversial uses for overloaded POST. The first is to *simulate* HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE" +> +> — [RESTful Web Services][cite], Leonard Richardson & Sam Ruby. + +## Browser based PUT, DELETE, etc... + +REST framework supports browser-based `PUT`, `DELETE` and other methods, by +overloading `POST` requests using a hidden form field. + +Note that this is the same strategy as is used in [Ruby on Rails][rails]. + +For example, given the following form: + + <form action="/news-items/5" method="POST"> + <input type="hidden" name="_method" value="DELETE"> + </form> + +`request.method` would return `"DELETE"`. + +## Browser based submission of non-form content + +Browser-based submission of content types other than form are supported by +using form fields named `_content` and `_content_type`: + +For example, given the following form: + + <form action="/news-items/5" method="PUT"> + <input type="hidden" name="_content_type" value="application/json"> + <input name="_content" value="{'count': 1}"> + </form> + +`request.content_type` would return `"application/json"`, and +`request.stream` would return `"{'count': 1}"` + +## URL based accept headers + +REST framework can take `?accept=application/json` style URL parameters, +which allow the `Accept` header to be overridden. + +This can be useful for testing the API from a web browser, where you don't +have any control over what is sent in the `Accept` header. + +## URL based format suffixes + +REST framework can take `?format=json` style URL parameters, which can be a +useful shortcut for determing which content type should be returned from +the view. + +This is a more concise than using the `accept` override, but it also gives +you less control. (For example you can't specify any media type parameters) + +## Doesn't HTML5 support PUT and DELETE forms? + +Nope. It was at one point intended to support `PUT` and `DELETE` forms, but +was later [dropped from the spec][html5]. There remains +[ongoing discussion][put_delete] about adding support for `PUT` and `DELETE`, +as well as how to support content types other than form-encoded data. + +[cite]: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260 +[rails]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work +[html5]: http://www.w3.org/TR/html5-diff/#changes-2010-06-24 +[put_delete]: http://amundsen.com/examples/put-delete-forms/ diff --git a/docs/topics/browserhacks.md b/docs/topics/browserhacks.md deleted file mode 100644 index 96cb1388..00000000 --- a/docs/topics/browserhacks.md +++ /dev/null @@ -1,43 +0,0 @@ -# Browser hacks - -> "There are two noncontroversial uses for overloaded POST. The first is to *simulate* HTTP's uniform interface for clients like web browsers that don't support PUT or DELETE" -> -> — [RESTful Web Services](1), Leonard Richardson & Sam Ruby. - -## Browser based PUT, DELETE, etc... - -**TODO: Preamble.** Note that this is the same strategy as is used in [Ruby on Rails](2). - -For example, given the following form: - - <form action="/news-items/5" method="POST"> - <input type="hidden" name="_method" value="DELETE"> - </form> - -`request.method` would return `"DELETE"`. - -## Browser based submission of non-form content - -Browser-based submission of content types other than form are supported by using form fields named `_content` and `_content_type`: - -For example, given the following form: - - <form action="/news-items/5" method="PUT"> - <input type="hidden" name="_content_type" value="application/json"> - <input name="_content" value="{'count': 1}"> - </form> - -`request.content_type` would return `"application/json"`, and `request.content` would return `"{'count': 1}"` - -## URL based accept headers - -## URL based format suffixes - -## Doesn't HTML5 support PUT and DELETE forms? - -Nope. It was at one point intended to support `PUT` and `DELETE` forms, but was later [dropped from the spec](3). There remains [ongoing discussion](4) about adding support for `PUT` and `DELETE`, as well as how to support content types other than form-encoded data. - -[1]: http://www.amazon.com/Restful-Web-Services-Leonard-Richardson/dp/0596529260 -[2]: http://guides.rubyonrails.org/form_helpers.html#how-do-forms-with-put-or-delete-methods-work -[3]: http://www.w3.org/TR/html5-diff/#changes-2010-06-24 -[4]: http://amundsen.com/examples/put-delete-forms/ diff --git a/docs/topics/credits.md b/docs/topics/credits.md index 539fa09e..a74f7983 100644 --- a/docs/topics/credits.md +++ b/docs/topics/credits.md @@ -46,6 +46,12 @@ The following people have helped make REST framework great. * Jamie Matthews - [j4mie] * Mattbo - [mattbo] * Max Hurl - [maximilianhurl] +* Tomi Pajunen - [eofs] +* Rob Dobson - [rdobson] +* Daniel Vaca Araujo - [diviei] +* Madis Väin - [madisvain] +* Stephan Groß - [minddust] +* Pavel Savchenko - [asfaltboy] Many thanks to everyone who's contributed to the project. @@ -57,6 +63,8 @@ Project hosting is with [GitHub]. Continuous integration testing is managed with [Travis CI][travis-ci]. +The [live sandbox][sandbox] is hosted on [Heroku]. + Various inspiration taken from the [Piston], [Tastypie] and [Dagny] projects. Development of REST framework 2.0 was sponsored by [DabApps]. @@ -78,6 +86,8 @@ To contact the author directly: [tastypie]: https://github.com/toastdriven/django-tastypie [dagny]: https://github.com/zacharyvoase/dagny [dabapps]: http://lab.dabapps.com +[sandbox]: http://restframework.herokuapp.com/ +[heroku]: http://www.heroku.com/ [tomchristie]: https://github.com/tomchristie [markotibold]: https://github.com/markotibold @@ -122,4 +132,10 @@ To contact the author directly: [cyberj]: https://github.com/cyberj [j4mie]: https://github.com/j4mie [mattbo]: https://github.com/mattbo -[maximilianhurl]: https://github.com/maximilianhurl
\ No newline at end of file +[maximilianhurl]: https://github.com/maximilianhurl +[eofs]: https://github.com/eofs +[rdobson]: https://github.com/rdobson +[diviei]: https://github.com/diviei +[madisvain]: https://github.com/madisvain +[minddust]: https://github.com/minddust +[asfaltboy]: https://github.com/asfaltboy diff --git a/docs/topics/csrf.md b/docs/topics/csrf.md index a2ee1b9c..043144c1 100644 --- a/docs/topics/csrf.md +++ b/docs/topics/csrf.md @@ -5,8 +5,8 @@ > — [Jeff Atwood][cite] * Explain need to add CSRF token to AJAX requests. -* Explain defered CSRF style used by REST framework +* Explain deferred CSRF style used by REST framework * Why you should use Django's standard login/logout views, and not REST framework view -[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html
\ No newline at end of file +[cite]: http://www.codinghorror.com/blog/2008/10/preventing-csrf-and-xsrf-attacks.html diff --git a/docs/topics/migration.md b/docs/topics/migration.md index f6a301b8..25fc9074 100644 --- a/docs/topics/migration.md +++ b/docs/topics/migration.md @@ -1,5 +1,9 @@ # 2.0 Migration Guide +> Move fast and break things +> +> — Mark Zuckerberg, [the Hacker Way][cite]. + REST framework 2.0 introduces a radical redesign of the core components, and a large number of backwards breaking changes. ### Serialization redesign. @@ -21,7 +25,7 @@ REST framework 2.0's request-response cycle is now much less complex. * Responses inherit from `SimpleTemplateResponse`, allowing rendering to be delegated to the response, not handled by the view. * Requests extend the regular `HttpRequest`, allowing authentication and parsing to be delegated to the request, not handled by the view. -### Renamed attribnutes & classes. +### Renamed attributes & classes. Various attributes and classes have been renamed in order to fit in better with Django's conventions. @@ -82,4 +86,4 @@ Let's start to re-write this for REST framework 2.0. model = Comment fields = ('username', 'comment', 'created', 'rating', 'url', 'blogpost') - +[cite]: http://www.wired.com/business/2012/02/zuck-letter/ diff --git a/docs/topics/changelog.md b/docs/topics/release-notes.md index 15fb6301..b336aeab 100644 --- a/docs/topics/changelog.md +++ b/docs/topics/release-notes.md @@ -1,8 +1,16 @@ -# Change Log +# Release Notes + +> Release Early, Release Often +> +> — Eric S. Raymond, [The Cathedral and the Bazaar][cite]. + +## Master + +* If PUT creates an instance return '201 Created', instead of '200 OK'. ## 2.0.0 -* **Fix all of the things.** +* **Fix all of the things.** (Well, almost.) * For more information please see the [2.0 migration guide][migration]. --- @@ -108,4 +116,5 @@ * Initial release. +[cite]: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html [migration]: migration.md
\ No newline at end of file diff --git a/docs/topics/rest-framework-2-announcement.md b/docs/topics/rest-framework-2-announcement.md new file mode 100644 index 00000000..885d1918 --- /dev/null +++ b/docs/topics/rest-framework-2-announcement.md @@ -0,0 +1,100 @@ +# Django REST framework 2 + +What it is, and why you should care. + +> Most people just make the mistake that it should be simple to design simple things. In reality, the effort required to design something is inversely proportional to the simplicity of the result. +> +> — [Roy Fielding][cite] + +--- + +**Announcement:** REST framework 2 released - Tue 30th Oct 2012 + +--- + +REST framework 2 is an almost complete reworking of the original framework, which comprehensively addresses some of the original design issues. + +Because the latest version should be considered a re-release, rather than an incremental improvement, we've skipped a version, and called this release Django REST framework 2.0. + +This article is intended to give you a flavor of what REST framework 2 is, and why you might want to give it a try. + +## User feedback + +Before we get cracking, let's start with the hard sell, with a few bits of feedback from some early adopters… + +"Django REST framework 2 is beautiful. Some of the API design is worthy of @kennethreitz." - [Kit La Touche][quote1] + +"Since it's pretty much just Django, controlling things like URLs has been a breeze... I think [REST framework 2] has definitely got the right approach here; even simple things like being able to override a function called post to do custom work during rather than having to intimately know what happens during a post make a huge difference to your productivity." - [Ian Strachan][quote2] + +"I switched to the 2.0 branch and I don't regret it - fully refactored my code in another ½ day and it's *much* more to my tastes" - [Bruno Desthuilliers][quote3] + +Sounds good, right? Let's get into some details... + +## Serialization + +REST framework 2 includes a totally re-worked serialization engine, that was initially intended as a replacement for Django's existing inflexible fixture serialization, and which meets the following design goals: + +* A declarative serialization API, that mirrors Django's `Forms`/`ModelForms` API. +* Structural concerns are decoupled from encoding concerns. +* Able to support rendering and parsing to many formats, including both machine-readable representations and HTML forms. +* Validation that can be mapped to obvious and comprehensive error responses. +* Serializers that support both nested, flat, and partially-nested representations. +* Relationships that can be expressed as primary keys, hyperlinks, slug fields, and other custom representations. + +Mapping between the internal state of the system and external representations of that state is the core concern of building Web APIs. Designing serializers that allow the developer to do so in a flexible and obvious way is a deceptively difficult design task, and with the new serialization API we think we've pretty much nailed it. + +## Generic views + +When REST framework was initially released at the start of 2011, the current Django release was version 1.2. REST framework included a backport of Django 1.3's upcoming `View` class, but it didn't take full advantage of the generic view implementations. + +With the new release the generic views in REST framework now tie in with Django's generic views. The end result is that framework is clean, lightweight and easy to use. + +## Requests, Responses & Views + +REST framework 2 includes `Request` and `Response` classes, than are used in place of Django's existing `HttpRequest` and `HttpResponse` classes. Doing so allows logic such as parsing the incoming request or rendering the outgoing response to be supported transparently by the framework. + +The `Request`/`Response` approach leads to a much cleaner API, less logic in the view itself, and a simple, obvious request-response cycle. + +REST framework 2 also allows you to work with both function-based and class-based views. For simple API views all you need is a single `@api_view` decorator, and you're good to go. + + +## API Design + +Pretty much every aspect of REST framework has been reworked, with the aim of ironing out some of the design flaws of the previous versions. Each of the components of REST framework are cleanly decoupled, and can be used independantly of each-other, and there are no monolithic resource classes, overcomplicated mixin combinations, or opinionated serialization or URL routing decisions. + +## The Browseable API + +Django REST framework's most unique feature is the way it is able to serve up both machine-readable representations, and a fully browsable HTML representation to the same endpoints. + +Browseable Web APIs are easier to work with, visualize and debug, and generally makes it easier and more frictionless to inspect and work with. + +With REST framework 2, the browseable API gets a snazzy new bootstrap-based theme that looks great and is even nicer to work with. + +There are also some functionality improvments - actions such as as `POST` and `DELETE` will only display if the user has the appropriate permissions. + +![Browseable API][image] + +**Image above**: An example of the browseable API in REST framework 2 + +## Documentation + +As you can see the documentation for REST framework has been radically improved. It gets a completely new style, using markdown for the documentation source, and a bootstrap-based theme for the styling. + +We're really pleased with how the docs style looks - it's simple and clean, is easy to navigate around, and we think it reads great. + +## Summary + +In short, we've engineered the hell outta this thing, and we're incredibly proud of the result. + +If you're interested please take a browse around the documentation. [The tutorial][tut] is a great place to get started. + +There's also a [live sandbox version of the tutorial API][sandbox] available for testing. + +[cite]: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724 +[quote1]: https://twitter.com/kobutsu/status/261689665952833536 +[quote2]: https://groups.google.com/d/msg/django-rest-framework/heRGHzG6BWQ/ooVURgpwVC0J +[quote3]: https://groups.google.com/d/msg/django-rest-framework/flsXbvYqRoY/9lSyntOf5cUJ +[image]: ../img/quickstart.png +[readthedocs]: https://readthedocs.org/ +[tut]: ../tutorial/1-serialization.md +[sandbox]: http://restframework.herokuapp.com/ diff --git a/docs/topics/rest-hypermedia-hateoas.md b/docs/topics/rest-hypermedia-hateoas.md index b58dfcb7..d7646892 100644 --- a/docs/topics/rest-hypermedia-hateoas.md +++ b/docs/topics/rest-hypermedia-hateoas.md @@ -4,7 +4,7 @@ > > — Mike Amundsen, [REST fest 2012 keynote][cite]. -First off, the disclaimer. The name "Django REST framework" was choosen 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". +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. @@ -22,17 +22,17 @@ For a more thorough background, check out Klabnik's [Hypermedia API reading list ## Building Hypermedia APIs with REST framework -REST framework is an agnositic 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. +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 *does* provide. +## What REST framework provides. It is self evident that REST framework makes it possible to build Hypermedia APIs. The browseable 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][fields] for building well-connected systems, and great support for [content negotiation][conneg]. -### What REST framework *doesn't* provide. +## What REST framework doesn't provide. -What REST framework doesn't do is give you is machine readable hypermedia formats such as [Collection+JSON][collection] or HTML [microformats] by default, or the ability to auto-magically create fully HATEOAS style APIs that include 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. +What REST framework doesn't do is give you is machine readable hypermedia formats such as [Collection+JSON][collection] 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. [cite]: http://vimeo.com/channels/restfest/page:2 [dissertation]: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm @@ -50,4 +50,4 @@ What REST framework doesn't do is give you is machine readable hypermedia format [parser]: ../api-guide/parsers.md [renderer]: ../api-guide/renderers.md [fields]: ../api-guide/fields.md -[conneg]: ../api-guide/content-negotiation.md
\ No newline at end of file +[conneg]: ../api-guide/content-negotiation.md |