The Dropbox API docs state that in the event of being rate limited, a 503 HTTP status code will be returned, with a "Retry-After" header. However, in what I suspect is a case of rate limiting, this is the actual reponse I get:
[503] Error parsing response body or headers: Body - '\r\n<html>\r\n<head><title>Dropbox
- 5xx</title>\r\n<link href="https://www.dropbox.com/static/css/ Headers - {'transfer-
encoding': 'chunked', 'server': 'nginx', 'connection': 'keep-alive', 'cache-control':
'no-cache', 'date': 'Sat, 31 May 2014 12:55:40 GMT', 'content-type': 'text/html'}
(Actually this is the str(e) of dropbox.rest.ErrorResponse as e)
There is no Retry-After header, so this may not be a case of rate limiting. If that's the case then I don't know what this error is telling me.
Does anyone have an example of an actual rate-limiting response that I can test against?
The response just indicates some random server glitch. You should try the request again. As you've indicated, this scenario is documented in the Standard API Errors section of the Core API Reference:
503
If the response includes the Retry-After header, this means your ... app is being rate limited. Otherwise, this indicates a transient server error, and your app should retry its request.
Related
I'm trying to set the value of the Content-Length property to 0 in my RAML file.
I first stumbled upon this thread : How to specify API request header value in RAML
When I tried implementing it with this code :
/update:
post:
description: Store updated data in database
headers:
Content-Length:
enum: [0]
body:
...
I got the response 400 Bad Request :
{
"code": "REQUEST_VALIDATION_ERROR",
"message": "Required header Content-Length is missing."
}
My IDE told me a string was expected but feeding with ["0"] didn't solve the problem.
(I'm testing my API specification in Mulesoft Design Center.)
So is there something I did wrong or is there another way to set the Content-Length to 0 in the request's header ?
You should only try to define custom headers in RAML. A required header of the HTTP protocol like Content-Length must not be defined. It should be automatically generated to prevent errors.
I'm trying to find out if a specific User is present in a supergroup, in order to keep track of those who left.
For that, I'm calling the Bot API method getChatMember for each User and checking if their status is either Left or Kicked. However, I noticed that (recently?) I'm getting USER_ID_INVALID errors for many valid users that are either in the supergroup or have been in the past and then left. I also confirmed that those accounts are still active on Telegram.
Here's the HTTP request I'm sending:
POST https://api.telegram.org/botXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXX/getChatMember HTTP/1.1
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
Content-Length: 46
Host: api.telegram.org
{"chat_id":-0000000000000,"user_id":000000000}
And here's the response I'm getting:
HTTP/1.1 400 Bad Request
Server: nginx/1.12.2
Date: Fri, 20 Apr 2018 04:17:32 GMT
Content-Type: application/json
Content-Length: 74
Connection: keep-alive
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
{"ok":false,"error_code":400,"description":"Bad Request: USER_ID_INVALID"}
Any way I look at it, it looks like a perfectly valid request to me. And I haven't been able to find a common pattern between the users that throw this error.
What am I missing here?
EDIT: As #sean pointed out, having one of those users message the bot privately fixed the error for that particular user. But I'm absolutely sure that user was seen before because that's how I got his user ID. What could have caused the bot "forget" about him and how would I prevent this from happening in the future?
This error means your bot haven't seen this user before.
For instance, my user ID is 109780439, you can try getChatMember with #PublicTestGroup, it should response with 400 error.
And then, forward ANY of my message (e.g., this) to your bot, you will see the different result :)
You will create a variable who get your channel's result, like this:
$join : api.telegram.org/botYOURTOKEN/getchat .....
if($message && (strpos($join,'"status":"left"') or strpos($join,'"Bad Request: USER_ID_INVALID"') or strpos($join,'"status":"kicked"'))!== false) {
}
I have the following code that works and I get the file output.txt. I would like for the output file to say success when it works and to provide error code when it doesn't.
import requests
import json
f = open('output.txt', 'w')
url = 'https://webapi.teamviewer.com/api/v1/account'
payload = {'name': 'alias', 'email': 'user#teamviewer.com'}
headers = {"content-type": "application/json", "Authorization": "Bearer myuser token"}
r = requests.put(url, data=json.dumps(payload), headers=headers)
f.write(r.text)
f.close()
TeamViewer HTTP Response codes are:
200 – OK: Used for successful GET, POST and DELETE.
204 – No Content: Used for PUT to indicate that the update succeeded, but no content is included in the
response.
400 – Bad Request: One or more parameters for this function is either missing, invalid or unknown. Details
should be included in the returned JSON.
401 – Unauthorized: Access token not valid (expired, revoked, …) or not included in the header.
403 – Forbidden / Rate Limit Reached: IP blocked or rate limit reached.
500 – Internal Server Error: Some (unexpected) error on the server. The same request should work if the
server works as intended.
You can get the result and error code from your response (assuming TeamViewer api is well behaved):
r = requests.put(url, data=json.dumps(payload), headers=headers)
if r.status_code == 200:
f.write('success')
else
f.write('{0}: {1}'.format(r.status_code, r.text))
Usually, we use POST to create a resource on the server-side.
So ideally if everything goes right, the server should respond either with a 201 Created HTTP status or in case of an asynchronous operation with 202 Accepted HTTP status.
Is there any valid scenario where a POST request can be returning a 200 OK HTTP status?
Or should we never use 200 OK HTTP status for a POST request?
I see 200 as a very common response to POST requests on internet. It's fine to use it.
From RFC 7231:
6.3.1. 200 OK
The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
GET a representation of the target resource;
HEAD the same representation as GET, but without the
representation
data;
POST a representation of the status of, or results obtained from,
the action;
PUT, DELETE a representation of the status of the action;
OPTIONS a representation of the communications options;
TRACE a representation of the request message as received by the
end
server.
And section 4.3.3:
Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [RFC7234]).
However, POST caching is not widely implemented. For cases where an
origin server wishes the client to be able to cache the result of a
POST in a way that can be reused by a later GET, the origin server MAY
send a 200 (OK) response containing the result and a Content-Location
header field that has the same value as the POST's effective request
URI (Section 3.1.4.2).
Yes, You can return 200 Ok HTTP status, but you SHOULD return a response BODY.
In general, we have 3 options according to your API requirements:
Return 201 Created HTTP status, with EMPTY BODY.
In case you don't need to return a response body.
Return 200 Ok HTTP status, with BODY.
In case you need to return a response body [containg created resource].
Return 202 Accepted HTTP status, with EMPTY BODY.
In case the action will be queued.
I'm writing a microservice for validating promo codes. The client sends me a promo code and a product ID (json). There is the 200 OK case where the code is good, I apply a discount for their order. But there is an error-ish case where the promo code doesn't apply for this product. I'm unsure what response code to use.
Should this also be 200 OK (with some sort of message saying the validation of the code fails)?
Should it be 400 Bad Request?
Neither seems entirely appropriate, it's odd to say 200 OK when it wasn't "OK", however 4xx is usually for signifying a problem with the structure of the request / http protocol - and in this case the structure of the request is fine.
I'll second steveax. 422 seems like a good choice.
IMHO, you should never use 200 if the request failed.
Use an error code & if necessary, provide details in the response body:
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
{ "reason": 1, "text": "Invalid promo code." }
On second thought, I think 403 is a good fit here:
HTTP/1.1 403 Forbidden
Content-Type: application/json
{ "reason": "bad_promo_code" }
Ultimately, it doesn't matter as long as it's documented.
I will suggest 409:
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request.