3 ms·
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 plac
by 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 agoGNU 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 agoI 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.