4 ms·

> 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 re

> 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 12y ago
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 12y ago
  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 12y ago
    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 12y ago
      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.
duaneb 12y ago
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 12y ago
  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 12y ago
    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.
ubercow 12y ago
Especially when a good majority of APIs require you to pass something like an OAuth token in the header, ruining the bookmarkibility completely.
deleted 12y ago
[deleted]
tessierashpool 12y ago
> 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.

andrewstuart2 12y ago

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 12y ago
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 12y ago
  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 12y ago
    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.

duaneb 12y ago

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 12y ago
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 12y ago
  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.

ubercow 12y ago

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

deleted 12y ago

[deleted]

tessierashpool 12y ago

> 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.