json=true to specify the content type. Ideally, this should be from the accept header, but at the very least it should be possible to only specify one content type. Right now, I can specify json=true&xml=true.
Only using GET.
Session management on the client. Why would I want to log someone out?
Not using meaningful keys. s and t? Why not status and token?
HTTP codes should be used instead of status codes.
I agree, content type selection currently is very rudimentary and ability to combine parameters could be confusing. We want to distinguish between JSON, JSONP, XML and CSV. We could use text/plain MIME type for CSV, text/xml for XML, but are there standard MIME types for JSON and JSONP?
> Only using GET.
API is currently immutable towards analytics data, so only GET is used.
> Session management on the client. Why would I want to log someone out?
It's less of the session management and more security token management. Log out is to revoke specified security token. We should be more explicit about this.
For JSONP, you might consider application/javascript (http://stackoverflow.com/questions/111302/best-content-type-...)
Specifying content type as a parameter this makes debugging so much easier that I think it is worth it.
I agree with your other points. Specifically, the output type should be done the same way Solr does it: http://wiki.apache.org/solr/CoreQueryParameters#wt
foo({"err":{"code":500,"msg":"oh no. i broke!"},"response":null})
foo({"err":null,"response":"hooray"})
Most frameworks (WSGI, Rack) allow you to wrap the response and check for presence of the callback, and transform into a friendlier jsonp format. Then you can simply ignore it and code as normal. In this case, doesn't express (seems to be what you are using?) support route middleware too?
Just because REST says you should do it one way doesn't mean you should.