Re: Change: Search API Rate Limiting
The error code for search rate limiting will be changing from HTTP 503 to HTTP 401 in the very near future (today or tomorrow). For details, continue reading. Are you sure you want to use 401 for this? 401 would indicate authorization required. If you're asking for credentials, that would make sense, but if you're not, I would think the 503 is still the proper response irrespective of broken proxies. I don't see other codes that have that one's temporal semantics. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [EMAIL PROTECTED] -- If you have integrity, nothing else matters. -- Alan Simpson ---
Re: Change: Search API Rate Limiting
Of course right after sending a lengthy public email I see something that could let us keep 503 and fix the proxy errors. I'm working with operations on that, and if it does not pan out I'll confer with Alex on 400 versus 401. Stay tuned. — Matt On Dec 8, 2008, at 09:46 AM, Alex Payne wrote: We use 400 for rate limiting on the REST API. Matt and I are discussing whether or not this might be the correct response. Thoughts? On Mon, Dec 8, 2008 at 09:17, Cameron Kaiser [EMAIL PROTECTED] wrote: The error code for search rate limiting will be changing from HTTP 503 to HTTP 401 in the very near future (today or tomorrow). For details, continue reading. Are you sure you want to use 401 for this? 401 would indicate authorization required. If you're asking for credentials, that would make sense, but if you're not, I would think the 503 is still the proper response irrespective of broken proxies. I don't see other codes that have that one's temporal semantics. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [EMAIL PROTECTED] -- If you have integrity, nothing else matters. -- Alan Simpson --- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x
Re: Change: Search API Rate Limiting
The error code for search rate limiting will be changing from HTTP 503 to HTTP 401 in the very near future (today or tomorrow). For details, continue reading. Are you sure you want to use 401 for this? 401 would indicate authorization required. If you're asking for credentials, that would make sense, but if you're not, I would think the 503 is still the proper response irrespective of broken proxies. I don't see other codes that have that one's temporal semantics. We use 400 for rate limiting on the REST API. Matt and I are discussing whether or not this might be the correct response. Thoughts? I guess that would work there too IMHO. It's ill-defined but that's a bonus in this case :) -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [EMAIL PROTECTED] -- Logic is the art of going wrong with confidence. -- George Bernard Shaw
Re: Change: Search API Rate Limiting
You could compromise and do a 400.5 O_o On Mon, Dec 8, 2008 at 11:51, Matt Sanford [EMAIL PROTECTED] wrote: Of course right after sending a lengthy public email I see something that could let us keep 503 and fix the proxy errors. I'm working with operations on that, and if it does not pan out I'll confer with Alex on 400 versus 401. Stay tuned. — Matt On Dec 8, 2008, at 09:46 AM, Alex Payne wrote: We use 400 for rate limiting on the REST API. Matt and I are discussing whether or not this might be the correct response. Thoughts? On Mon, Dec 8, 2008 at 09:17, Cameron Kaiser [EMAIL PROTECTED] wrote: The error code for search rate limiting will be changing from HTTP 503 to HTTP 401 in the very near future (today or tomorrow). For details, continue reading. Are you sure you want to use 401 for this? 401 would indicate authorization required. If you're asking for credentials, that would make sense, but if you're not, I would think the 503 is still the proper response irrespective of broken proxies. I don't see other codes that have that one's temporal semantics. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [EMAIL PROTECTED] -- If you have integrity, nothing else matters. -- Alan Simpson --- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- | Abraham Williams | Web Developer | http://abrah.am | Brazen Careerist | Pro Hacker | http://www.brazencareerist.com | PoseurTech LLC | Mashup Ambassador | http://poseurte.ch | Web608 | Community Evangelist | http://web608.org | This email is: [] blogable [x] ask first [] private
Re: Change: Search API Rate Limiting
I think using 400 is much easy to handle the responses than using 401. Because I can use same http client code and same error handling code for both search API and REST API. In my case, I wrote a error handler which alerts a dialog whenever it gets a 401 because search API wouldn't return 401. On Mon, Dec 8, 2008 at 9:56 AM, Abraham Williams [EMAIL PROTECTED] wrote: You could compromise and do a 400.5 O_o On Mon, Dec 8, 2008 at 11:51, Matt Sanford [EMAIL PROTECTED] wrote: Of course right after sending a lengthy public email I see something that could let us keep 503 and fix the proxy errors. I'm working with operations on that, and if it does not pan out I'll confer with Alex on 400 versus 401. Stay tuned. — Matt On Dec 8, 2008, at 09:46 AM, Alex Payne wrote: We use 400 for rate limiting on the REST API. Matt and I are discussing whether or not this might be the correct response. Thoughts? On Mon, Dec 8, 2008 at 09:17, Cameron Kaiser [EMAIL PROTECTED] wrote: The error code for search rate limiting will be changing from HTTP 503 to HTTP 401 in the very near future (today or tomorrow). For details, continue reading. Are you sure you want to use 401 for this? 401 would indicate authorization required. If you're asking for credentials, that would make sense, but if you're not, I would think the 503 is still the proper response irrespective of broken proxies. I don't see other codes that have that one's temporal semantics. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [EMAIL PROTECTED] -- If you have integrity, nothing else matters. -- Alan Simpson --- -- Alex Payne - API Lead, Twitter, Inc. http://twitter.com/al3x -- | Abraham Williams | Web Developer | http://abrah.am | Brazen Careerist | Pro Hacker | http://www.brazencareerist.com | PoseurTech LLC | Mashup Ambassador | http://poseurte.ch | Web608 | Community Evangelist | http://web608.org | This email is: [] blogable [x] ask first [] private
