[davidism]

> A GET query is always a URI. Anyone can link to it.

Except this isn't really useful outside of bookmarks in a browser. Who would bookmark an API endpoint returning JSON? In code, it's just as easy to make a request with query parameters as it is with a post body.

    #!/usr/bin/env python
    import requests
    requests.get('http://example.com/', params={'key': 'value'})
    requests.post('http://example.com/', data={'key': 'value'})

[andrewstuart2]

Which endpoint (or resource locator) you hit probably shouldn't dictate the representation type you get back. That's what the `Accept:` headers should be used for. If you hit it with a browser, you'd expect to get back some html version of the same resource.

If you use "Accept:application/json", then you should expect to get JSON back. Etc.

[davidism]

A fair point. I was referring to the api being separate from the frontend, not what the api is returning. But I could see someone designing their application the way you describe.

[treve]

And when someone does design their application in that manner, the various benefits of doing things 'right' start to pay off.

If a resource or result is addressable it means that a 3rd party can build an API that integrates with my API and link straight to results of certain queries.

Granted that this would be hard in the context of the dropbox API, because they already 'break' a lot other rules.

[davidism]

Yes, if reusable/sharable queries are something you want, then you don't really have a choice but to expose an API for creating and retrieving them. Not sure if you're trying to make some other point related to the `Accept:` header the parent comment was about.

[tessierashpool]

> this isn't really useful outside of bookmarks in a browser.

a GET query's "always-URI" status is useful to caching proxies. so going against the protocol could mean you have additional work to do configuring your proxies.

[ubercow]

Especially when a good majority of APIs require you to pass something like an OAuth token in the header, ruining the bookmarkibility completely.

[duaneb]

Also, the behavior of a GET can change based on the headers. (think: basic auth.) So no, it can't be purely linked to.

[treve]

I think, if an API is well-designed, you should strive to not let the resource change depending on the authorization headers.

Ideally, they should only make a difference in the fact that access is granted, or not (401 for bad authentication, 403 if you're simply not allowed).

This is not possible everywhere, but it's definitely something to try to aim for. If you can't, you can still use facilities such as the Vary header to indicate that the authorization header alters the result.

[duaneb]

I'm just pointing out that GET requests and linkable URLs are very different things. Even consider Accept headers—it's perfectly valid to respond with different content if the request wants it.