Updated REST framework 2 roadmap (markdown)

Tom Christie 2013-12-05 00:43:30 -08:00
parent 1dc20bc762
commit 29afceb2d2

@ -58,6 +58,35 @@ For example:
* ~~Send raw data in browseable API~~ **Done**
* Pre-emptive ETag / Last modified support
## Update - plans for REST framework in 2014.
The main priority for REST framework as it currently stands is to continue to build on it's stability, and keep on top of the issue backlog, so that we can be responsive to any issues that come in.
New features should almost alway be aimed at third party packages at this point, and we need to do everything we can to help contributors build an ecosystem around a stable core, rather than expanding too much more.
There are still some valid pieces that *need* to be in core, in particular.
### Writable nested serializers.
This has been pending for a long time, and the bulk of the work is done. Needs documenting thoroughly in order to thrash out some remaining edge cases, and when *finally* complete, this will be the headline feature for a 2.4.0 release.
### GET forms in browsable API.
Still the same as above - we need filters to expose some kind of API that allows the Browsable API to hook into and display appropriate controls corresponding to the installed filters (eg search, ordering, etc)
### Pre-emptive ETag / Last modified support.
Proper caching support has been discussed and @ghickman has had a first stab at it, but needs more work, see the issue list for corresponding ticket on this one.
### Hypermedia.
In the interests of pushing forward the state APIs, and promoting hypermedia approaches I'd strongly consider including renderers for the `HAL` and `DocJSON` hypermedia types as a baseline, with other hypermedia types aimed as third party packages. One thing that'd probably need to happen here would be for `reverse` to return a `hyperlink` type object instead of a raw string, so that hypermedia renderers can treat links appropriately.
There are also a number of tasks that I think would be worth pursing as third party packages:
**Bulk upload views**: REST framework supports bulk uploads, but the generic views don't include it by default. A set of views that do support bulk uploads would be great.
**HTML plus API views**: HTML views need a different set of conventions to standard renderers - typically you'll want to add in more context, furthermore context data does not need serialized as it is instead rendered in the template. Responses such as `201 Created` may need to instead be translated into redirects, and `204 No content` is not a reasonable response. A set of views that allow developers to easily write web apps that expose both the API and the App with the same set of views. Believe @md4d has started some work on this.
**noSQL implementations**: Packages that contain a full set of views and serializers for supporting a particular noSQL backend. Similarly it might also be useful to have an SQLAlchamy implementation.
[#7]: https://github.com/tomchristie/django-rest-framework/pull/7
[#8]: https://github.com/tomchristie/django-rest-framework/pull/8