Maybe because of the overhead on rendering time and extra bytes.
On a couple thousand requests the latency is not so noticeable. But on the long run maybe the API user should have a plugin on the client side to do that kind of beautification.
Not necessarily. You would only render the prettified version when the client has an Accept header that shows more capabilities than application/json.
Which, by the way leads to my single complaint with this API: it only renders JSON.
To call it truly "self-documenting", I should just browse to http://www.heyzap.com/api/v1/ (ok, second complaint: the "v1" also belongs in a header, not the URI) and get an HTML page describing the resource, and links to the other endpoints. Bonus points if this HTML allows me to run the queries with overridden parameters.
You have a point with the rendering option from the accept header...
About the v1 versioning in the URL, I understand your suggestion. But I see that little characteristic as a "no developer left behind" program for developers with less experience.
Also the format as an extension for your resource serves the same purpose
Perhaps this would be a good place to tie into the "Accept:" request header? If it says text/html in Accept:, you're still going to return JSON, but you can use this as a hint that it is probably being read by a human, and you can pretty print it.
But if you see application/json in Accept:, then you assume it's an API call from a phone or script and you minify it instead.
Edit: however, that requires cooperation from others, so is prone to failure. Perhaps also take hints from the user agent string?
Edit 2: drat, someone already beat me to this suggestion. However, I'll use this as an excuse to pimp my last weekend hack: adding an Accept: decorator to itty.py http://news.ycombinator.com/item?id=3665743
Because your browser provides Accept: text/html by default you get back a nice html page describing the result for the API root. If you send Accept: text/json (click "json" at the bottom) you get back a json response.
You can follow the links in the html response to get to other parts of the API. You can also click "OPTIONS" to send an OPTION request to get a description of what you can send to that endpoint.
How well does django-rest-framework do with nested (foreignkey) resources? I recently chose Tastypie for a project for that reason alone, but never ran across django-rest-framework to have considered it.
Looking at the django-rest-framework API examples, that's one thing I don't see, but is (at least for me) fairly critical.
It handles them fully. I haven't played with the many to many support, but from having looked through the code it fully supports getting/setting many to many relationships.
One thing that does seem to be a bit lacking is the documentation. I've used all three django frameworks though (piston, tastypie and django-rest-framework) and django-rest-framework wins in my book.
Can you get any of those three frameworks to expose arbitrary views? One of my biggest complaints with all of them is that they seem to only expose objects.
When you say objects I assume you mean model objects? In that case yes. I haven't used Piston or Tastypie in awhile, but I know that you can easily write views in django-rest-framework that aren't tied to models.
This is a bullet from the django-rest-framework page I linked above: "Modular architecture - MixIn classes can be used without requiring the Resource or ModelResource classes."
I read through both of those links and I think I wasn't clear with my initial question.
I want to expose arbitrary view methods to GET calls, not linked to any model, and not have to write a new class for every view I want to expose. Basically I want views to return the correct filetype (json, html, xml, etc) when requested. This is basically making django a little more rails-like. I'm leaning towards django-dynamicresponse currently.
I really like how the three you mentioned tie into Django's forms though, and that's quite a feature to give up.
Yes, you can get djangorestframework to be used without being tied to any model, or even without tying it to a resource. In its current incarnation, djangorestframework just follows the principle from generic class-based views.
You just define a view that inherits from djangorestframework.views.View, and implement the action methods (get/post/put/delete) that you want. These methods must return a dictionary, and the framework handles the part of dispatch and render the view in the proper format.
They are talking specifically, it seems, about RESTful and related API's, but self-documenting API's IMO should be present at other levels of an application too.
I would take it further and say that truly self-documenting API's should be discoverable by software as well as individuals. This is something we have worked on hard at LedgerSMB, doing so with stored procedures even (see http://ledgersmbdev.blogspot.com/2011/10/introduction-to-sod... for more info).
Anywhere there is a connection between software, this can be a good approach. Why limit it to the web?
When I saw the /v1 prefix I was reminded of one of Steve Klabnik's blog posts[1], where he gives an alternative, arguably more RESTful approach to versioning an API.
Hey, I addressed this point in the blog post. I disagreed with that because a) its not self-documenting. b) On v2 the exact same URLs will have completely different data and probably break every API consumer.
What about the ability to look at API responses in a browser? You can't normally change the request headers a browser sends without some type of plugin.
Including the version number in the URL gets around this and even allows you to test API responses in mobile browsers if needed.
Although I tend to agree that a header-based approach is cleaner and more in the spirit of REST and even HTTP.
Well, I think the way you do it is provide examples of interaction that sends an explicit Accept with client interactions. Detecting Content-type and reacting accordingly is only for totally blind discovery.
