4 ms·

I always thought API versions in URLs had more to do with efficient URL routing than RESTful semantics. If you're Twitter or AWS and handling tens of millions

I always thought API versions in URLs had more to do with efficient URL routing than RESTful semantics. If you're Twitter or AWS and handling tens of millions of requests a day it would (seem) far less resource intensive to determine routing based on a pre-defined URL structure than to inspect the headers of each incoming API request. It might also save development time. So you have your block of v1 API servers and your block of v2 servers, without having to re-code the v1 stack to also parse v2 requests.

schrodinger 13y ago
Is it really any more resource intensive to inspect a header vs a url? Why?
- girvo 13y ago
  Uneducated guess: The URL is always looked at, and further up the stack too, whereas headers might not be passed down to the client explicitly?
- leepowers 13y ago
  You can scan a URL very quickly: http://myapi.mysite/v1/user/new http://myapi.mysite/v2/tweets/fetch The version identifier is always in the same place. HTTP headers come in an unordered list. And a client can send any number of headers to the API. And the version identifier may be at the beginning of the list, in the middle, the end, any position really. Even so, I doubt the resource usage is very different per-request. But writ large it may make a difference.
  - icebraining 13y ago
    GNU Grep can search for a string in 41000 files in 1.2s (that's with open(), mmap(), close(), etc). I really doubt that web frameworks are so optimized that matching a particular header would take any perceivable time.
  - mrec 13y ago
    I wouldn't worry too much about the cost of parsing. I'd be a lot more concerned about APIs that rely on proxy and UA caches for performance and/or scaling. A request has a much better chance of getting cached reliably if all the important semantics are in the path than if they're in arbitrarily-ordered querystring args or headers. Squid's default config didn't cache anything with a querystring up through v3. OldIE wouldn't cache an uncompressed response with any Vary headers. I suspect there are landmines like this buried all over the place.
- joesb 13y ago
  Would it be a problem in HTTPS, since you cannot inspect HTTPS headers in the proxy?
  - icebraining 13y ago
    You can't inspect the path either, only the domain, and even that's only if the browser is using SNI.
  - schrodinger 13y ago
    In the context of a load balancing proxy, you apply the SSL cert to the proxy, and do the encryption there - known as SSL termination. Otherwise like you said, the proxy can't see inside the request (not even the URL).

schrodinger 13y ago

Is it really any more resource intensive to inspect a header vs a url? Why?

girvo 13y ago
Uneducated guess: The URL is always looked at, and further up the stack too, whereas headers might not be passed down to the client explicitly?
leepowers 13y ago
You can scan a URL very quickly: http://myapi.mysite/v1/user/new http://myapi.mysite/v2/tweets/fetch The version identifier is always in the same place. HTTP headers come in an unordered list. And a client can send any number of headers to the API. And the version identifier may be at the beginning of the list, in the middle, the end, any position really. Even so, I doubt the resource usage is very different per-request. But writ large it may make a difference.
- icebraining 13y ago
  GNU Grep can search for a string in 41000 files in 1.2s (that's with open(), mmap(), close(), etc). I really doubt that web frameworks are so optimized that matching a particular header would take any perceivable time.
- mrec 13y ago
  I wouldn't worry too much about the cost of parsing. I'd be a lot more concerned about APIs that rely on proxy and UA caches for performance and/or scaling. A request has a much better chance of getting cached reliably if all the important semantics are in the path than if they're in arbitrarily-ordered querystring args or headers. Squid's default config didn't cache anything with a querystring up through v3. OldIE wouldn't cache an uncompressed response with any Vary headers. I suspect there are landmines like this buried all over the place.
joesb 13y ago
Would it be a problem in HTTPS, since you cannot inspect HTTPS headers in the proxy?
- icebraining 13y ago
  You can't inspect the path either, only the domain, and even that's only if the browser is using SNI.
- schrodinger 13y ago
  In the context of a load balancing proxy, you apply the SSL cert to the proxy, and do the encryption there - known as SSL termination. Otherwise like you said, the proxy can't see inside the request (not even the URL).