GSoC 2007 Status Update VIII: Django REST interface
for your pet projects, please give it a try, test, test, test, create tickets for any bugs you find and then, test some more. Thank you, Malcolm Tredinnick, for great advice and great patience. Next time, I will try to reduce the number of times I made your head explode and your brain leak out of your nose a bit :-). I am also grateful to anyone who asked questions or suggested features and, of course, to the community of Django developers in general. I hope you like and use the Django REST interface. Cheers, Andreas Stuhlmüller [1] http://code.google.com/p/django-rest-interface/ [2] http://www.aiplayground.org/artikel/improving-django/ [3] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/ [4] http://code.google.com/p/django-rest-interface/issues/list [5] http://groups.google.com/group/django-developers/msg/00481aec2ef71a38 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update VII: Django REST interface
On 8/17/07, David Larlet <[EMAIL PROTECTED]> wrote: > Just one (latest?) thought, it's a bit hard to debug because > 400 errors are not really verbose, is it possible to find a > way to make debug easier? For the moment, I have: if > settings.DEBUG: print i.errors but I'm sure it can be better. I made the 400 error template a bit more verbose. The responder classes that use serializers include the model errors in their responses anyway. Is this what you were looking for? > In fact, the problem is that you use ResourceForm in > model_resource and it could be interesting to use the given > form_class instead. You're right, it might be nice to be able to change the validation and data cleanup behavior of resources. Check out the latest revision and tell me if this is along the lines you were thinking. Regards, Andreas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update VII: Django REST interface
This is the seventh status update for my Summer of Code project, the Django REST interface [1]. Last week, I extracted code from the ModelResource class that is not directly related to models but useful for resources in general, moved it to Resource and made ModelResource inherit from Resource. I added an example of a non-model-based resource and corresponding tests. The generic resource class now uses the same kind of authentication that ModelResource uses. You can now run "python manage.py syncdb; python manage.py runserver" in the django_restapi_tests folder and get a testable environment that includes some initial data. I added code for forms to TemplateResponder (create_form, update_form), an example that shows how to use this code and another example that shows how to specify the data format at the end of your URLs. A few days ago, I started writing a short tutorial [2] that describes how to provide an API for an existing Django application using the REST interface. If you have any questions, ideas, can't get the interface to work or want to contribute bugfixes and other enhancements, please go ahead. Regards, Andreas Stuhlmüller [1] http://code.google.com/p/django-rest-interface/ [2] http://code.google.com/p/django-rest-interface/wiki/RestifyDjango --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update VI: Django REST interface
On 8/11/07, David Larlet <[EMAIL PROTECTED]> wrote:
> Here is my suggestion: the current forms from model or instance are
> great but you often need a custom form, what about an extra-argument
> to the collection (better because I already need a form in the
> collection in order to return a creation form on the list view, about
> that if you have better idea...) or the responder with the form class?
Forms seem to be relevant only if you use TemplateResponder, therefore
I am against adding form-specific code to ModelResource. You can
already specify extra_context for TemplateResponder. Might that be
sufficient?
> * in order to be consistent with template, the name should be related
> to elem._meta.module_name and not self.template_object_name
Fixed, thanks.
> About urls, how can I get a "reversed url". For example, is it planned
> to deal with {% url %} tag and permalink? I've tried to do this
> without any success.
This should definitely be possible, but I have not found an elegant
way to do this yet.
> So thank you for your awesome work and I will not hesitate to fill
> a bug (and maybe to help if GSoC allow that) if I find one.
Once the SoC final evaluation is over (Mon, August 20th), it will be a
lot easier (=possible) for me to work together with other people and
to accept code contributions. This strikes me a little strange since
SoC is supposed to encourage work within the open source community but
what you end up with is "work on your own, supported by your mentor"
(which, admittedly, works quite well).
Regards,
Andreas Stuhlmüller
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update VI: Django REST interface
On 8/6/07, David Larlet <[EMAIL PROTECTED]> wrote: > * What about additional pages like: create form, update form, delete > confirmation and so on? I've just noticed the get_create_form at the > end of the TemplateResponder but how can I redirect to this function? > (I haven't seen how to do this in url generation.) > * How can I deal with custom forms for a resource? I extended the template example to include a create form and an update form [1]. Note that you need something like HttpMethodsMiddleware [2] in order to use the update form and that the forms are currently not redisplayed after erroneous input. For any other forms and extensions, just write views and add the URLs to urlpatterns (above the catch-all resource URLs). If you feel that the REST interface should support this kind of work and have ideas how this might look like, please let me know. > * Is it possible to specify the format at the end of an url or will it > break the parsing? Yes, this is possible if you specify the urlpatterns for collection and entry individually. I just added such an example [3]. > And last but not least, what is the current stability? If you can, wait at least until Fri, August 24th before using the REST interface in any kind of production environment. By then I hope to have done more thorough testing. If you stumble upon a bug, please let me know. Thanks for your feedback. Regards, Andreas Stuhlmüller [1] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/template.py [2] http://www.djangosnippets.org/snippets/174/ [3] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/fixedend_urls.py --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update VI: Django REST interface
This is the sixth status update for my Summer of Code project. You can find more information as well as an updated timetable at [1]. During the last two weeks, I mainly worked on unit tests and on simplifying the relationship between the REST interface and URLs. I added manage.py, settings.py and tests.py in order to enable tests with Django's unit testing framework, converted the existing tests, removed the old (now obsolete) test files, added fixtures and restructured the HttpDigestAuthentication code in order to allow testing without a web server and httplib2. You now need to specify the URLs for collections and entries within urlpatterns. This change is backwards-incompatible. See the five examples [2] which replace the large urls.py example for more information on how to use the interface. The URL generation logic now uses reverse(). The class for collection entries can be specified in the Collection() constructor call. Thanks to David Larlet for recommending the the __call__ trick as a replacement for the dispatch() methods. I am currently reading "RESTful Web Services" by Leonard Richardson and Sam Ruby. See [3] for a summary of the main points from the chapter on best practices for REST-oriented architectures with short notes on where the REST interface still needs improvement. If you feel that there are important issues I am missing, please write me or just open a ticket [4]. Regards, Andreas Stuhlmüller [1] http://code.google.com/p/django-rest-interface/ [2] http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/examples/ [3] http://code.google.com/p/django-rest-interface/wiki/BestPractices [4] http://code.google.com/p/django-rest-interface/issues/list --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update IV: Django REST interface
On 7/13/07, David Larlet <[EMAIL PROTECTED]> wrote: > * About users, how can I handle django users' permissions? John > Sutherland had already done some work on django-crudapi [1] and it > could be interesting to allow this access control. Good question. I would subclass one of the authentication classes, e.g. HttpBasicAuthentication, and add a has_perm() check dependent on the request method to is_authenticated(). Currently, REST authentication is independent from Django's authentication middleware. It might make sense to move most of the code in HttpBasicAuthentication and HttpDigestAuthentication to django.contrib.auth.backends and to let the middleware do most of the work. > I'm not fond of CRUD names and I prefer to keep an information on > the HTTP verb in the function name but it's maybe personal. I chose the CRUD names as they better describe what the methods actually do, but if the consensus is that it is more important to highlight the HTTP method, I will change this. > * About dispatch, why don't you use the __call__ trick? Fixed, thanks for the pointer. > * About verbs, I know this is not really GSoC related but what is the > recommended way to handle fake PUT and DELETE from a browser? The > HttpMethodMiddleware[4]? Maybe a simple form/deletion in the polls > application will be an interesting example for a real django case. Yes, I recommend HttpMethodsMiddleware [4]. I just added a "delete" button to the template example and verified that it works if you add HttpMethodsMiddleware to your middleware classes. Thanks for your comments! Regards, Andreas [4] http://www.djangosnippets.org/snippets/174/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update V: Django REST interface
On 7/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Would it be possible to, instead of passing in collection_url_pattern
> to the Collection, pass in the name of a named url pattern, which
> internally would get reverse()'d?
Yes. After talking to Malcolm about how URL customization could be
made easier, I intend to add a view function, e.g. rest_view, that
handles detecting the method and dispatching based on that. Both
automatically generated and custom patterns would then look like this:
url('^/articles/(?P\w+)/$', rest_view,
entry_method_map, "article-entry")
url('^/articles/$', rest_view,
collection_method_map, "article-collection")
with
entry_method_map = {
'GET' : get_view,
'PUT' : put_view,
'DELETE : delete_view
}
collection_method_map = {
'GET' : get_view,
'POST' : post_view
}
In order for automatic URL generation to work, you could pass the URL
pattern to the Collection() instantiation call. When the URL for an
individual model is needed, we just reverse() the entry URL pattern.
Note that in the the above example we might replace the url() call
with an api_url() call that saves us from repetitive definitions.
Regards,
Andreas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update V: Django REST interface
On 7/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I would love to try it out with one of my apps, but maybe a really > quick HOWTO on how it's supposed to be set up with a project? Thanks for the suggestion! I just added a short tutorial to the project page [1]. The five steps contain only the most basic things needed to get the REST interface running. If anything is unclear or doesn't work as expected, please let me know. You don't need to add anything to INSTALLED_APPS. As long as the API definitions remain relatively simple, just use urls.py. Once you inherit from Collection and write custom resource methods, it might make sense to store your classes somewhere else in the view layer and just import from there. How the long-term guideline regarding where to store API code will look like depends on a) how the URL generation feature changes and b) which insights we gain from the work on the non-model-based part of the project. I will remember your point when I write the documentation on how to use the API. Regards, Andreas [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update V: Django REST interface
This is the fifth weekly status update for my Summer of Code project [1]. Since it is the last update before I take two weeks off to study for my exams (as arranged with my mentor), this is probably a good time to sum up the current status of the project and to talk about what's left to do. The basic framework is done. If you feel experimental, give it a try and take a look at the RESTful API for your Django models, the serialized (JSON, XML) or templated output, the authentication mechanisms and the automatically generated URL patterns. Of course, I can't give any guarantee that by the end of the SoC project any specific feature will still look like it does now -- and I am fairly certain that it will be a lot easier to use custom URLs then than it is now. I am currently in the process of moving the tests to Django's unit testing framework. This turns out not be quite as as straightforward as I thought (e.g. there is no simple alternative to httplib2's add_credentials method for authentication tests), therefore I will continue working on that after my break. Besides finishing up the model resource part (this includes URL generation, unit tests and a few smaller issues), my main objective for the remaining time will be to think about how we can make it easier to write REST APIs that don't correspond 1:1 to models. If I wanted to implement the Atom Publishing Protocol in Django, what would I do? Is there code that needs to be written for almost every REST app in some way or the other and that we can take care of? Expect the next update around July 20th. Regards, Andreas Stuhlmüller [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update IV: Django REST interface
This is the fourth weekly status update for my Summer of Code project, a generic REST interface for Django [1]. Issues I worked on this week: 1. Authentication. I added authentication hooks to the Collection class, an implementation of HTTP Basic and Digest authentication (stateless, header is sent with each request), authentication tests and a function that connects HTTP Basic auth with Django's User model. 2. Continued work on URL generation. It is now possible to overwrite all URLs by subclassing Collection. The distinction between methods that return URLs and methods that return URL patterns got clearer. The URL generation part of the REST interface is still going to change a lot. 3. Appropriate error messages. I added methods to JSONResponder and XMLResponder that return mimetype-specific error responses which include a human readable error message, application-specific errors (e.g. missing ) and a machine readable status code. According to my initial timetable, next week is reserved for writing unit tests and documentation. Although not complete, I have already written quite a few tests along the way. The main task will be to fit these tests into Russell's unit testing framework. Another issue that needs to be resolved next week is that authentication should allow different levels of access to the same resource for authenticated and unauthenticated users. As always, criticism, ideas and suggestions are welcome! Regards, Andreas [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update III: Django REST interface
This is the third weekly status update for my Summer of Code project, a generic REST interface for Django [1]. I spent the SoC-part of this week mostly thinking about automated URL pattern generation, wrote some code and added a few tests that demonstrate how to use this feature. Currently, you can: 1. Let the REST interface generate all your API URLs automatically. 2. Give a custom base URL and let the REST interface do the rest. 3. Subclass model_resource.Collection, overwrite Collection.get_entry and (if you want to filter the data returned) Collection.read, and use arbitrary custom URLs. I am not completely happy with how this works yet. Using custom URLs should be as intuitive as using automated URLs, and I don't think that's the case yet. If you see how things could be improved, please let me know. Other changes I made this week include the option to restrict model field access via expose_fields and better error handling (all exceptions are caught in Collection.dispatch, the Responder class is responsible for returning a nicely formatted error message). Besides thinking about how custom RESTful URLs could be implemented in a more intuitive way, my main task for next week is to think about the relationship between the REST interface and authentication. It should be possible to have different levels of access for authenticated and unauthenticated users. Criticism, ideas and suggestions are welcome! Regards, Andreas [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update II: Django REST interface
This is the second weekly status update for my Summer of Code project, a generic REST interface for Django [1]. This week, I was mostly working on improving the architecture of the code, in particular by splitting ModelResource into two classes, Collection (for querysets) and Entry (for individual models). Other improvements include appropriate HTTP status codes for POST/PUT requests, the option to use templates for the response formatting (TemplateResponder), basic pagination (works both with serialized and templated output) and load_put_and_files, a function that populates request.PUT and request.FILES via _load_post_and_files. Compared to my initial timetable, I am in time. Looking at my last status report, I notice that error handling isn't perfect yet (needs to be unified) and the option to limit the model fields exposed by the API and the inclusion of resource URIs in serialized output are not done yet. The main thing I will do next week is to think about and improve automated URL generation. I am still working on the first part of my proposal (resources that correspond directly to models). If you have any thoughts on what should or should not be possible with such a REST API or if you have specific comments on the code, please let me know. Regards, Andreas [1] http://code.google.com/p/django-rest-interface/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: GSoC 2007 Status Update: Django REST interface
On 6/2/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > Django is a web development framework, and not model development. REST > (XMLRPC/SOAP) API are created to expose webservices, which by definition > could be anything, not just models. CRUD is myopic world view. Thanks for your comment! You are right in saying that making models CRUD-accessible is just a small part of what should be possible with the REST API. That's why my proposal includes two parts: Easily configured CRUD method access patterns for models on the one hand and resources that don't correspond 1:1 to models on the other hand. I will take a closer look at the tickets you opened when I get to the second half of my proposal, but note that what I am working on is not XMLRPC or SOAP. Regards, Andreas On 6/2/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote: > On 6/1/07, Andreas Stuhlmüller <[EMAIL PROTECTED]> wrote: > > This week, I have started checking in code. I am always happy about > > feedback. Add a few lines to your (non-production!) urls.py [1], make > > your models available in XML or JSON format and tell me what works for > > you and what doesn't. > > I contributed patch for > http://code.djangoproject.com/ticket/547, and tho did not > object much when it was closed in favor of > http://code.djangoproject.com/ticket/115, but I feel both > your approach and #115 are wrong. > > Django is a web development framework, and not model development. REST > (XMLRPC/SOAP) API are created to expose webservices, which by definition > could be anything, not just models. CRUD is myopic world view. Have you seen > the API's that Flickr/Delicious/FaceBook exposes? *None* of them are > (strictly) CRUD related. What should you make easy is making any python > function available through REST, and that function can in turn implement > CRUD if you want. I am not against CRUD api, but thats a very small, and in > my opinion unused subset of what REST etc would be used for. > > Developers, please relook at 547, and compare it with 115. 547 is closed by > jacob saying " This is a subset of #115." which I feel is not the case, as > #115 is "Models CRUD via web services". > > Related bug: http://code.djangoproject.com/ticket/552 > > -- > Amit Upadhyay > Vakow! http://www.vakow.com > +91-9820-295-512 > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
GSoC 2007 Status Update: Django REST interface
This is the first weekly status update for my Summer of Code project, a generic REST interface for Django. If you haven't seen it, take a look at http://code.google.com/p/django-rest-interface/. This week, I have started checking in code. I am always happy about feedback. Add a few lines to your (non-production!) urls.py [1], make your models available in XML or JSON format and tell me what works for you and what doesn't. Compared to my timetable, I have managed to start a few things I planned to get done next week or the week after (create/update/delete operations, basic url patterns generator) and I have yet to add the option to format output with templates, something I wanted to get done by today. Besides templates, I am going to work on error handling, pagination, the option to limit the model fields exposed by the API, a _load_put_and_files equivalent to _load_post_and_files and the inclusion of resource urls in serialized output until next Friday. Regards, Andreas [1] Like this: http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/urls.py --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: magic-removal: where_constraints
On 2/14/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > my first stumbling block I have found is that I was using > 'where_constraints' to automatically set the SITE_ID. > > how does one do this in magic_removal? I replaced the where_constraints by overwriting the default query sets. See http://code.djangoproject.com/wiki/RemovingTheMagic#YoucanoverridedefaultQuerySets. Using python parameters instead of SQL is a nice improvement over the where_constraints method. Andreas
Re: Magic - removal branch .. is the API stable yet?
On 1/23/06, Jason Davies <[EMAIL PROTECTED]> wrote: > I'm keen to get the "semantics of subtyping" stuff done. If you have > any implementation hints to help me along that would be really helpful, > thanks. Same here. I'd love to see a working subtyping implementation for magic removal, the sooner the better. If there is anything I can do to help just drop me a note. Andreas
