5 ms·

This surprises me a bit: "All requests should be made via the POST method, and all parameters should be passed in the POST request-body and not in the query-st

by piokoch 11y ago

This surprises me a bit: "All requests should be made via the POST method, and all parameters should be passed in the POST request-body and not in the query-string." So even typical GET are sent as POST (/api/1/bookmarks/list) Is there any reason to do that?

hartror 11y ago
It gets even better: > If the response is not valid JSON, it should be interpreted as an HTTP 503 "Service Temporarily Unavailable" error, and the request should be retried later. Why not just return 503?
- mrec 11y ago
  Maybe it does, normally. But there's always an outside chance that everything's fine at the point you start writing a response, but goes pear-shaped before you finish. This wording just reinforces what's probably common sense, i.e. that there's no reason you'd see invalid JSON other than a hopefully-transient operational issue.
  - hartror 11y ago
    In what circumstances does a HTTP server/client return to a partially complete response?
paulhallett 11y ago
I think we've encountered another situation where developers who don't fully understand HTTP best practices and standards, are asked to adapt their internal API services to work on the web :(
hartror 11y ago
The xAuth authentication method is suspect as well: xAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user. https://dev.twitter.com/oauth/xauth https://dev.twitter.com/oauth/xauth Asking users to trust third parties with the access details to your application? Sure they "review" the API token requests but who knows what that means. Reading the page there seems to be a lot of talk about "keeping it simple" as if using the HTTP protocol is hard and confusing for developers. This is a bad sign, if they don't understand or care to understand something simple what are their security practices like?
masklinn 11y ago
> Is there any reason to do that? That it's RPC over HTTP, POSTing everything is the normal (and, really, proper) way to do RPC over HTTP.

by piokoch 11y ago

hartror 11y ago

It gets even better: > If the response is not valid JSON, it should be interpreted as an HTTP 503 "Service Temporarily Unavailable" error, and the request should be retried later. Why not just return 503?

mrec 11y ago
Maybe it does, normally. But there's always an outside chance that everything's fine at the point you start writing a response, but goes pear-shaped before you finish. This wording just reinforces what's probably common sense, i.e. that there's no reason you'd see invalid JSON other than a hopefully-transient operational issue.
- hartror 11y ago
  In what circumstances does a HTTP server/client return to a partially complete response?

paulhallett 11y ago

I think we've encountered another situation where developers who don't fully understand HTTP best practices and standards, are asked to adapt their internal API services to work on the web :(

hartror 11y ago

The xAuth authentication method is suspect as well: xAuth provides a way for desktop and mobile applications to exchange a username and password for an OAuth access token. Once the access token is retrieved, xAuth-enabled developers should dispose of the login and password corresponding to the user. https://dev.twitter.com/oauth/xauth https://dev.twitter.com/oauth/xauth Asking users to trust third parties with the access details to your application? Sure they "review" the API token requests but who knows what that means. Reading the page there seems to be a lot of talk about "keeping it simple" as if using the HTTP protocol is hard and confusing for developers. This is a bad sign, if they don't understand or care to understand something simple what are their security practices like?

masklinn 11y ago

> Is there any reason to do that? That it's RPC over HTTP, POSTing everything is the normal (and, really, proper) way to do RPC over HTTP.