A RESTful Django?
Rob Hudson
Imagine built-in REST URLs the encompass the same functionality that
the admin has:
* get list of models
* get list of all objects in model X
* get/update/delete/add object
* etc.
>From there, the admin and getting at the content could become many
things:
* Desktop applications that talk to the REST backend (XUL, QT, GTK,
etc)
* Lots of ways to pull/push data outside of Python
* Lots of other ideas, I'm sure.
[1] A few blog posts:
Ajax and REST, Part 1 and Part 2:
http://www-128.ibm.com/developerworks/java/library/wa-ajaxarch/
http://www-128.ibm.com/developerworks/java/library/wa-ajaxarch2.html
The REST Dialogues (starting with part 1)
http://duncan-cragg.org/blog/post/getting-data-rest-dialogues/
James Bennett
> Imagine built-in REST URLs the encompass the same functionality that
> the admin has:
It's actually been talked about a lot; the problem is no-one's ever
actually sat down and written the code for it.
Want to be the first? ;)
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
gabor
> On 11/17/06, Rob Hudson <trebor...@gmail.com> wrote:
>> Imagine built-in REST URLs the encompass the same functionality that
>> the admin has:
>
> It's actually been talked about a lot; the problem is no-one's ever
> actually sat down and written the code for it.
>
> Want to be the first? ;)
>
hmm.. i think the hard part is not really the technical implementation.
i attached a VERY simple version that lists apps/models/objects. the
"write" methods are not implemented, but wouldn't be that hard imho.
but on the other hand, i don't think it's such a good approach.
i like REST,
but for me it's more on the "service" level.
in other words, it's similar to how URLs relate to objects in django.
they certainly relate to each other in a way,
but it's not that every object has an url, etc...
you design your URLs, to represent your "API" to your application.
the same way, if i would offer REST access to my application,
i would design the REST interface separately, and would not publish all
my objects (models) through REST.
of course, this all is imho :)
gabor
James Bennett
> hmm.. i think the hard part is not really the technical implementation.
> i attached a VERY simple version that lists apps/models/objects. the
> "write" methods are not implemented, but wouldn't be that hard imho.
Well, what I personally would really like (and admittedly I haven't
looked at your code yet to see what it implements) is some option when
I'm defining a model that lets me say "give this a REST API with the
following operations available". That way I can choose, in the model
definitions, to say that my blog entry model should expose an API to
let me post remotely, but that the auth user model shouldn't (to take
an example).
Failing that, something like the feed framework where I could write a
dead simple API class to interface to a model or set of models would
be awfully nice :)
Rob Hudson
> Well, what I personally would really like (and admittedly I haven't
> looked at your code yet to see what it implements) is some option when
> I'm defining a model that lets me say "give this a REST API with the
> following operations available". That way I can choose, in the model
> definitions, to say that my blog entry model should expose an API to
> let me post remotely, but that the auth user model shouldn't (to take
> an example).
So, something like an alternative to "class Admin"? ...
class MyModel(models.Model):
field1 = models.CharField(maxlength=100)
field2 = models.CharField(maxlength=100)
field3 = models.CharField(maxlength=100)
class Rest:
# Exclude 'create' and 'delete'
allowed_operations = ('read', 'update')
expose_fields = ('field1', 'field2')
# Maybe some things like this?
# key maps to site ID or explicitly set by a method?
require_api_key = True
# to set unique keys for users?
api_key_method = path.to.api.method
Just like Admin, those models with out a Rest inner class would not be
exposed. This would also need a url config to map to
django.contrib.rest.urls, for example.
> Failing that, something like the feed framework where I could write a
> dead simple API class to interface to a model or set of models would
> be awfully nice :)
Of the two ideas, the first is definitely more powerful.
But I can start to see the models.py file getting cluttered if Django
goes down this path. First it was an inner class for the Admin, then
an inner class for REST, then the other things that came along.
Has there been any considerations to other inner-classes? And is there
concern for clutter in the models.py? If so, are there other ways to
set up those settings? Perhaps a separate admin.py file that defines
the Admin options for the sibling models.py file?
-Rob
Jacob Kaplan-Moss
> But I can start to see the models.py file getting cluttered if Django
> goes down this path. First it was an inner class for the Admin, then
> an inner class for REST, then the other things that came along.
I don't think you need an inner class for REST. In fact, I think it's a
pretty bad idea; how would I expose, say, two different APIs to the same
content? Maybe I want a anonymous read-only API to live alongside a
developer-token based read-write API...
I was picturing a meta-REST system as working similar to generic views; you'd
do it all in your urlconf. So, adapting your example, I'd expect something
like this::
from myapp.models import MyModel
from django.conf.urls.defaults import *
from django.contrib import restapi
api = dict(
queryset = MyModel.objects.all(),
allowed_operations = ('read', 'update'),
expose_fields = ('field1', 'field2'),
authentication_method = restapi.APIKeyAuthentication
)
urlpatterns = patterns('',
(r'^mymodel/rest/(?P<url>.*)$', restapi.api)
)
Of course I'm just sketching here, but the important part is that stuff
dealing with REST shouldn't be in the model; the view level (of which the
URLconf is a part) is the right place for it.
Jacob
James Bennett
> I don't think you need an inner class for REST. In fact, I think it's a
> pretty bad idea; how would I expose, say, two different APIs to the same
> content? Maybe I want a anonymous read-only API to live alongside a
> developer-token based read-write API...
I agree inner classes are not the way to go. On further reflection I
think you're also right about putting API definitions into the URLConf
or, at the very least, the view layer. I kind of like the idea of
defining an API as a class -- much like we do with feeds and sitemaps
-- and then pointing a URL at that.
Michael Radziej
similar to what you could use. The purpose of the class is that
it can be used to serve data in various formats (for use with
ajax), and still provides the data directly as QuerySet or
similar, so that the form or view can use the same data directly.
I've attached it in case someone's interested, just to express
the idea. The class provides a viewlet for csv. You might add
other formats and could write generic views to use it.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company