4👍
I’d take a look at piston, tastypie and django-rest-framework, honestly they’re mostly pretty similar, I’d just take a run through the docs and see which you think fits the bill.
I don’t think any of those will natively support the Range pagination you mention it’s probably something you’d need to deal with yourself.
Piston is the daddy, tho not being actively maintained ATM, that’s not necessarily and issue as it pretty much does what you want anyway. Tastypie’s advantages are that it has a great community behind it, and is well documented. django-rest-framework has the admin style API browser, plenty of examples in the docs, and a growing community. django-rest-interface is perfectly decent AFAIK, but I don’t know of any community effort behind it ATM.
3👍
Django grids has a long list of REST projects: http://djangopackages.com/grids/g/rest/ , but it doesn’t really list features. Although, what features do you want? It’s a rest interface, it should be able to do the right thing depending on the HTTP method used, and return the right serialization depending on the Accept
header sent. They all do this, as far as I can tell.
I’ve been using (the pbs-education fork of) Piston and Tastypie, trying to get them to work the way that I want. And I’m about to play with django-rest-framework. Here’s some things that I’ve run into, though:
-
Piston in general does a pretty good job of handling things, but it has a couple of weird bugs where it swallows the status codes of things that I tried to throw. (My hacks around that are online) And nobody’s maintaining it, and there are a lot of open bugs in the main issue tracker. Some of them have patches, probably, and some of them are probably WONTFIXs, but 139 open bugs is a lot for a project that isn’t very big and, more to the point, has seen two commits in the last 2.5 years.
But it does work, and well enough for loads of people to still use it. And it is very flexible, and it’s small enough (only a few files) that I was able to monkey-patch in good-enough fixes for my use cases pretty quickly, after only “hours” of frustration.
-
Tastypie does a lot of work for you. And is kind of amazingly well documented. And it does several things the way that I want them to be done. But, if you look at the docs, its URI scheme for related–and especially nested–resources is ass-backwards, and it requires hacks (reasonably well-documented hacks, but still) to get them to work correctly.
This has got to be a result of how much Tastypie does for you: unlike Piston (and django-rest-framework? Its docs seem to suggest that it’ll do the work for you, too, but I haven’t actually used it) you don’t need to write CRUD functions or url schemes. Which, you know, great, except that my scheme isn’t completely flat so I need to hack around the dispatch methods and also I don’t know that its built-in HATEOAS machinery is going to match up to my crazy hacks. It’ll still return valid URIs, but will they be the ones I want people to use? (Probably there’s some function that does this, there are lots of places to hook in to Tastypie, but I can’t find a “canonical_url” anywhere in the Resource methods.)
So: Piston is very flexible but kinda dead, Tastypie is not flexible but great if you’ve got a very simple graph, and I haven’t touched django-rest-framework yet. Those seem like the big ones around right now.
1👍
What’s the difference between the above projects?
Please do that yourself, matching the projects against your requirements, not against each other.
Will either help me with the stated goal?
Yes.
Are there any others projects I might want to look at for this task?
Piston.
- [Django]-Django sitemap static pages
- [Django]-NameError: name PositiveSmallIntegerField is not defined
- [Django]-Django Registration Redux: how to change the unique identifier from username to email and use email as login
- [Django]-How to store HDF5 (HDF Store) in a Django model field