On Sat, 2007-03-17 at 14:53 +0000, [EMAIL PROTECTED] wrote:
> I recently began a new project to implement (as much as possible) pure
> REST within Django in a way that fits with Django's approach to Web
> development:
>
> django-restful-model-views
> http://code.google.com/p/django-restful-model-views
[...]
> Even if I am on the right track with this approach, the question still
> remains if implementing pure REST in Django is worth using this
> contribution. I suspect the answer depends on how much you care about
> REST, otherwise, the more natural, standard, semi-RESTful way of using
> Django is pretty darn good, and much simpler.
You seem to building a lot of your argument on a small strawman here and
it's important to realise that. You speak of "pure REST" and your code
makes it easy to expose model methods directly via a web interface. That
(equating front- and back-end entities) isn't a requirement, or even a
recommendation, of REST architecture methods. REST resource !=
middle-tier object (meaning "not always equal"). Sometimes? Yes, but
that's more accidental happenstance or thanks to a very simple system of
objects.
This can be a stumbling block for people trying to design REST
interfaces, because they spend a lot of time attempting such a mapping.
Having a web interface layer provides a good chance to
simplify/uniformise some of the complexity in the underlying object
model. I don't mean that always as "a chance to fix problems", but
sometimes the underlying model is complex of necessity, whereas the user
interface need not be.
(There's also a minor point in your first blog post that you seem to
associate REST with "things done through a web browser", which is a bit
of an artificially limiting constraint. There are a lot of useful
REST-based interfaces around that are designed to be talked to by other
software that isn't a web browser.)
Django neither enforces nor discourages REST-inspired access patterns.
However, it does make it easy to build them (so it does encourage that
style). See the examples below for why the URL <-> model method mapping
is too restrictive for all REST applications. I think, therefore, it's
an error to write that what you have developed is pure REST and Django
is semi-RESTful.
What you have done (with a nice design, by the looks of it), is provide
a relatively low-effort way for people who want to directly expose model
methods in this fashion.
> But, it may also be that
> on large, complex applications, this approach may help more logically
> organize application code.
The danger is that it also might encourage people to put methods on
their models that do more than just affect that model (see examples).
It's not a given that this leads to more logical application code and we
could debate that all day without reaching a firm conclusion, since one
man's logical is likely to get that same man fired for writing
unmanageable code in another scenario.
A couple of concrete examples to illustrate the points I'm trying to
make above:
(1) The Atom Publishing Protocol (APP) provides a resource (called the
Service Document) one can retrieve which acts as a way to discover the
available publishing endpoints. This does not really correspond to any
concrete object at the storage layer, although you could do it with a
configuration object, I guess. In a version I've written in Django, most
of this information is auto-discovered by a view function, so the
resource returned has no concrete back-end representation.
(2) Imagine a blog posting system. The creation of an entry might
require sending a multipart form containing a couple of file uploads
(images), and the text and then all this has to split up so that
articles go to one model, images go somewhere else, images need to have
their correct URL put into the post, links may be split out so that they
can be checked for validity later on (I have a blog system that stores
links in a separate model to make it easy to check them even months
later and it automatically checks all existing links periodically) and
so on. None of these actions are the responsibility of just a single
model, so forcing it into that mode is not really brilliant software
design. However, it does use REST architecture as far as creating,
editing, retrieving and deleting resources goes. However, clearly the
web-provided interface's idea of resource is not in one-to-one
correspondence with the database and ORMs' idea of an object/resource.
There are plenty of equivalents to the second example as well, just in
case it might sound like the blog post idea is contrived. Sending an
image to an APP-enabled system is one case (the system would create a
Media Resource and a Media Link Resource). Everybody's favourite travel
booking system example (the generic REST example) has similar cases.
There are also situations where the response to a POST or a PUT,
particularly, might need the HTTP headers set in some fashion. So, if
you were going to do this all in the model, suddenly the model method
isn't just working with the model ("self"). It's also having to be aware
of (and receive) the "request" object and have knowledge of HTTP.
Having written all of the above, I think what you have written (based on
my reading of your blog postings. I haven't read the source code yet),
is a reasonable implementation of an HTTP-visible CRUD (create,
retrieve, update, delete) interface for the ORM. In the past when people
have proposed this, I've always quietly thought it isn't appropriate for
Django's core (or contrib/) because I'm not comfortable with exposing
the middle tier like that and it's only applicable in limited cases.
However, it might be that there is a wide wish for that particular set
of cases and the code you've written seems like a well thought-out
attempt to provide the interface (after all, the same limitation applies
to Django's generic views and it's not like they are unpopular). I'm
going to read through the code when I get a chance, because it's nice
that this has been implemented: we can point everybody else towards it
when they ask.
Your approach to providing an interface for model CRUD-related methods
looks reasonable and non-repetitive for the user, but I wanted to make
clear that I think that's what you have done, not any kind of solution
to "how to fix REST in Django" (which would beg the question, for a
start). Avoiding misconceptions by using accurate naming and terminology
is pretty important in Open Source projects. Despite what we might hope,
there's a lot of the proverbial judging of reading material by their
outer containing pages.
In conclusion, thanks for writing and announcing this piece of code,
regardless of the impression I may have given above about your
nomenclature.
Best wishes,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
