Hi Karol, Thanks for bringing that up. I'll start by saying that I would love to see richer Web API support in core Django - in my opinion there are absolutely some fundamentals that could be addressed. However, I personally think that the benefit that we'd get probably isn't (yet?) worth the very large amount of work that would be required. I'll get onto that in a moment, but I'm first going to go through some of the core components that could be addressed...
Request parsing is an obvious one. Right now it's actually quite awkward to deal with parsing form data in anything other than POST requests. There's subtleties to get right for supporting both url-encoded and multipart forms, handling charset encodings, handling corrupt data, and dealing with the various possible states of the underlying stream. That gets more complicated again if you want to support both form data and json or other content types. That sort of thing has to be tackled each time by every new API framework, and it'd be a good candidate for better support in core. REST framework's approach is to introduce a `request.DATA` that supports parsing arbitrary content types depending on which parser are registered (either globally or per-view). Something similar in Django would be valuable, because it's a minimal amount of API, but addresses a fundamental issue. Serialization is another fundamental that's currently lacking. This is a deceptively difficult area, particularly the deserialization and validation aspects. Django's forms aren't sufficient for many of the use-cases you need to support with APIs. A mature, complete serialization framework needs to be able to support nested objects, various types of representation for relationships, support for both ORM and non-ORM data, serializing and deserializing from composites of models (eg both User data and UserProfile data in a single representation), and various other bits & pieces. Ideally a serialization framework should be flexible enough that it's equally capable of rendering a model instance into an HTML form representation, as it is of rendering it into JSON. Furthermore, if someone wanted to get a serialization framework into Django it'd make sense if it could also be used to replace the existing fixture loading/saving. Getting a really decent serialization framework into Django would obviously be a valuable thing to do, as it'd give us all a common, well-supported way of doing for Web APIs what forms currently allow us to do in Web apps. However, it'd evidently require a very large amount of work to successfully land in Django. Content negotiated responses are another possible candidate. Content negotiation is a core component of Web APIs, but we've currently no support in Django for dealing with it. There's not any great value in each new API framework solving content negotiation again, because there's a reasonably consistent set of rules about how it should be handled. Being able to return a response and have it render into various formats depending on the client request is something that could be dealt with in core Django once, and then reused by any API framework. Another area worth mentioning is authentication - in particular CSRF protection. The right way to deal with CSRF protection in Web APIs is non-obvious. Session authentication is valid for AJAX clients, and should require CSRF protection. Other authentication types such as OAuth are also valid but should not require CSRF protection. Handling that in a correct, secure way is fiddly, and something that I'm personally a little uncomfortable with API frameworks having to individually deal with. I think it's feasible that we could address some of these core ares, and still leave plenty of space for API frameworks on top of Django to experiment and thrive, while improving the baseline support for folks using just Django. Back to the point, though. The amount of work that'd be required to comprehensively address this in core would be pretty huge. We're in decent situation at the moment, with at least a couple of great, really well-supported API frameworks as third-party packages. Having those packages independent to Django is disadvantageous in that it fragments the already limited resources of our community, but it's also advantageous in that they can iterate more quickly than core Django, as well as being able to take opinionated design decisions that suit their domain. Django's ecosystem is pretty much it's biggest strength. In my opinion the cheapest, most beneficial option would be to look at ways to better promote third party packages from within the documentation. Obviously there's some discussion to be had about how to do that in a fair and open way, while still allowing an element of curation and ensuring that packages meet a required quality. Calling out quality packages in some way from the docs would help new users find their way around the ecosystem, help build communities around successful packages, and be a good incentive to maintainers. It's hard to know exactly what the most appropriate way to do this would be, but it does feel a little odd at the moment that third-party packages bring so much to Django, yet are rarely explicitly pointed to in the documentation. If there was a wide consensus from the core dev team that improving Web API support within core Django was something that needs addressing, and a drive to make it happen, then I guess the priorities would change. For now, continuing to build the communities behind the various third party packages seems like a pretty decent, low-cost win. Thanks, Tom On Saturday, 18 May 2013 11:26:53 UTC+1, Karol Sikora wrote: > > Hi, > > We was talked with Russell on djangocon eu about integrating more rich > support for working django as rest api provider, focused on dealing with > one-page web applications. > The motivations that currently without third party modules like > django-rest-framework or tastypie its quite impossible to create rich web > applications working as one-page. > As django aims to follow "batteries included" philosophy, so maybe it will > be a good idea to integrate support for dealing with modern web > applications. > > Better rest apis support conists from two parts: models(and other data > sources) serialization and handlers. > Django has currently limited support for simple serialization in > django.core.serializers, but its quite useless in creating rest apis. > Ideally serialization support should have: > * possibility to serialize data to any format by plugabble serializers(in > core i thing xml and json should be included), > * great integration with django models through eg, adding mixin class to > model class definition > * possibility to integrate with other data sources(approach with appending > mixin to class with data fields seems to be good for dealing with this case) > * possibility to provide data mutators as method in api class > * permissions mangement using user object > > I propose approach to create class which can work either as mixin to model > classes or as standalone base for other data sources. In this object we can > configure serializer class, set up permissions and mutator methods. > This class should have endpoint method like rest_get(self, user, *args, > **kwargs), which will be called from view/other to get serialized data, > rest_get, rest_post, rest_put and so on(getting request as first parameter > i think). > Validations should be integrated through forms I think, its quite mature > and stable soultion, I dont see any argument to build custom solution. > Serializers should take care on privileges checking, as its coupled with > user models. As we provide deep integrations with models it seems to be a > good solution that follows "fat models" approach. > > Next thing is dealing with http request. We propose to use CBV and based > on them create light wrappers to define handled http verbs, provide > serializer class and errors handling. > > The question is, what You're thinking about whole concpet(maybe we won't > integrate rest api supports in django core and redirect peoples to use > django-rest-framerwork and similar projects), maybe my ideas are good but > You find some holes on it? > > We're read to implement this solution and maintain them in the future. > > Waiting for Your opinion! > > Karol > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. For more options, visit https://groups.google.com/groups/opt_out.
