A RESTful Django?

James Bennett wrote:
> 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


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/22/06 10:43 AM, Rob Hudson wrote:
> 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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/22/06, Jacob Kaplan-Moss <jacobjacobian.org> wrote:
> 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.



-- 
"May the forces of evil become confused on the way to
your house."
  -- George Carlin

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I'm working on a class for a different purpose, but it looks

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


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---