I'm trying to find a list of standard gmail api error codes. Is there DoubleClick search API here: Standard Error Responses.
How about for Gmail? And will the response codes change? If I see a specific error is returned for ex with 409, can I hardcode 409 in my application?
Thanks,
MT
It should be safe to hardcode them, They have not changed for a long time.
Here are some quota-related error codes
https://developers.google.com/gmail/api/v1/reference/quota
Related
We are using the Yammer API to obtain statics for various of our clients.
We have the correct access token for all of them but for some we are receiving this error: The remote server returned an error: (401) Unauthorized..
The zip file generated does not get downloaded.
Example call: https://www.yammer.com/api/v1/export?model=Message&model=Group&model=Topic&model=UploadedFileVersion&model=DocumentVersion&access_token=xxxxxx-XkwP1lZFYYTF1NGrpFGmuw&include=csv&include_ens=false&since=2015-02-24T00%3A00%3A00%2B00%3A00
When pasting the link in a new tab a file not found is shown.
Does anyone have an idea what the problem may be or does know another way of getting the desired data?
I'm trying to get the list of albums as it is written here: https://developers.google.com/picasa-web/docs/1.0/developers_guide_protocol#ListPhotos
GET https://picasaweb.google.com/data/feed/api/user/default
Authorization: Bearer MY_ACCESS_TOKEN_HERE
So, the problem is that I get "404 Unknown user" responce. Strange thing but when I make the same request with the same access token from another PC, I get the correct responce (200 OK and list of albums).
I didn't google anything useful except the similar issue which was on API for Python (like here: AuthSub: (404, 'Not Found', 'Unknown user.')). Did anyone face the same issue?
So, the problem was that Google Photos server handles the requests incorrectly, if these requests contain some wrong Cookie headers.
I say "incorrectly" because other Google APIs (like Drive, Contacts, etc.) didn't have this issue.
So, all that I had to do is to add flag INTERNET_FLAG_NO_COOKIES in InternetOpenUrl function:
InternetOpenUrl(NetHandle, PChar(Url), PChar(Header), Length(Header), INTERNET_FLAG_RELOAD or INTERNET_FLAG_NO_COOKIES, 0);
After that sending HTTP requests using InternetOpenUrl with the flag won't return this error anymore.
When I try to fetch contacts from gmail, I received this error message:
The page you have requested cannot be displayed. Another site was requesting access to your Google Account, but sent a malformed request. Please contact the site that you were trying to use when you received this message to inform them of the error. A detailed error message follows:
The site "http://url.com" has not been registered.
May I know how to rectify it? Thanks!
Have you tried registering the domain with Google's API?
docs:
https://developers.google.com/accounts/docs/RegistrationForWebAppsAuto#new
resgister url:
https://accounts.google.com/ManageDomains
Also if you are making calls from http and not https you may be seeing problems there too.
When constructing an API response, which method is better for (manually) returning the status code to indicate the validity of the request:
1 - Embed a response code within the JSON response
{
'status_code' => 200,
'status_message' => 'OK',
'data' => { ... }
}
2 - Or is it better to modify the HTTP Headers Status field?
Request URL:http://somesite.com
Request Method:GET
Status Code: 200 (EDITING THIS ONE)
I would think that the HTTP Statuses should only be regarding connection errors and file retrieval errors that occur at the server level rather than altering this to address application level errors.
Any good articles and resources to read would be very appreciated as well.
I have found the best way to present errors in a REST Request is to change the HTTP Status Code to the proper error, and embed the error in the response.
If you are using JSON, it might look like this, with the status code set to 500 for this example:
{"error" : "An error has occurred while trying to read from the database."}
This is the same method that Microsoft CRM uses to report errors, and it has proved to be a good method; RESTFul applications will not fail to parse the response if they are expecting JSON (or XML, if you are using that).
This question addresses the same issue (perhaps from a slightly different perspective).
I think that, in general, if a request to a resource in your application results in an error condition, that fact should be reflected in the HTTP headers. You can use the application response to provide more detailed information.
Update: Here is an interesting mapping of application errors to status codes (used by Azure).
What is optimal HTTP response Code when not reporting 200 (everything OK) but error in input?
Like, you submit some data to server, and it will response that your data is wrong
using 500 looks more like Server Issue
using 200 with warning/error response text is bad (allowing caching and everything is not OK)
using 204 and returning nothing, is maybe good (but well supported?)
using 404 is wrong if requested path (script) is available and in proper place
We had the same problem when making our API as well. We were looking for an HTTP status code equivalent to an InvalidArgumentException. After reading the source article below, we ended up using 422 Unprocessable Entity which states:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.
source: https://www.bennadel.com/blog/2434-http-status-codes-for-invalid-data-400-vs-422.htm
Codes starting with 4 (4xx) are meant for client errors. Maybe 400 (Bad Request) could be suitable to this case? Definition in http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html says:
"The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. "
409 Conflict could be an acceptable solution.
According to: https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
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. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The doc continues with an example:
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
In my case, I would like to PUT a string, that must be unique, to a database via an API. Before adding it to the database, I am checking that it is not already in the database.
If it is, I will return "Error: The string is already in the database", 409.
I believe this is what the OP wanted: an error code suitable for when the data does not pass the server's criteria.
I recommend using 418 when client request something absurd that the server can't process. Like the server is a teapot but client is requesting coffee kind of stuff. Here is all the (400–499) client side error messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses
404 - Not Found - can be used for The URI requested is invalid or the resource requested such as a user, does not exists.