REST framework 2 roadmap

General synopsis.

Firstly, and above all, thank you. I've been amazed with the response to 2.0, and I'm incredibly happy with the little community we're starting to build here. I think we've got an absolutely rock-solid set of foundations now, and I'm really looking forward to helping the project mature into a world-class API framework. Again, thank you for all the incredible help in getting to this point.

Overall goals.

I guess the big picture here is taking this from a pet-project into a community-owned effort.

I'm going to try to be liberal in handing out the commit-bit.
If there's anything you think I ought to be doing differently in terms of how we run this project please feel free to chime in - I don't have a problem with constructive criticism.
Any ideas on how to help make the project more community-owned are appreciated. (Maybe consider moving to a github organization repo?)
I'd like to do everything I can to encourage third-party maintained add-ons (eg. custom serializers, filtering backends, auth, throttling etc.) Keeping the maintenance cost of the project down is going to be one thing that really helps it stay healthy in the long term.
In terms of project maintenance, going to continue to focus on keeping that issues list well under control, and be ruthless in keeping the core API simple & clean.
I'd really like to run sprints at DjangoCon Europe and (maybe, maybe) DjangoCon US (at the very least I'll try to help do something remotely). If you have an employer who might pay your conference ticket, the start of the year would be a really good time to talk to them, so start thinking about it now.

Milestones.

The following are the major features I'd like to see added to the framework.

Py3k support.

~~Coming along very nicely, thanks to @xordoquy. See #464.~~

Writable nested serializers.

Currently being tackled by @maspwr. See #536, and related tickets. This is a tough one. I reckon we could probably split of some parts of this if anyone also wants to work on it. (Eg. at some point we'll need to think about complex stuff like how we deal with rendering serializers as nested HTML forms.)

OAuth.

~~Speaks for itself. This really shouldn't be hard, just needs a little legwork - someone needs to make the time to get it done, tested and nicely documented. See #8.~~ Completed by @dulaccc and @swistakm.

RawFileUpload parser.

~~Not sure if this should be a milestone or not, but feels like a really nice feature to me. See #7 for details. (Yes it really is that old.)~~ Completed by @wronglink

HTMLFormRenderer.

Support for rendering serializers directly into HTML. Kind of supported via the browseable API, but it'd be nice to be able to directly render them into an HTML form, without the convert-to-a-Form-object-first approach that's currently used. Shouldn't be tricky, and would be rather nice. See #310. Completed by @tomchristie

Resources & routers.

See resources-routers branch. Automatic URL routing and resource registering, as per Rails, Tastypie & Dagny. The design work is basically done, so if anyone wants to pick this up we can work on it together. Will require a bit of code and a big chunk of documentation, plus an extra section in the tutorial. This has been put off a couple of times in the past as I wasn't happy with the fundamentals, but I think there's a really nice design now, and I think I'd be happy for it to go it. Completed by @tomchristie (Now called ViewSets and Routers)

GET forms in browseable API.

When a filter backend is configured for a view, provide an HTML form for it in the browseable API. I think django-filter does almost all of what we need for that already, so just a case of tying into that, making it work okay with the bootstrap theme, and documenting it a little.

...and other nice to haves.

For example:

~~Proper authenticate responses~~ Done
~~CSV Support~~ Done
~~Digest authentication~~ Done
~~Bulk updates~~ Done
~~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.

Pagination API overhaul.

Using serializers for the pagination API is unnecessarily complex, and also doesn't allow us to easily use other pagination styles such as header based pagination links. Ideally we'd introduce a new pagination API, and include a few different default styles.

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.