I'm trying to to get a response from this sandbox endpoint
sandbox-api.uber.com/v1/requests/resource_id/map
instead of getting something like this
{
"request_id":"b5512127-a134-4bf4-b1ba-fe9f48f56d9d",
"href":"https://sandbox-api.uber.com/v1/sandbox/map"
}
why am I getting this response?
{
"message": null,
"code": "conflict"
}
With the same Bearer token and resource_id I'm getting the right response to this endpoint sandbox-api.uber.com/v1/requests/resource_id/map
Thank you!
It looks like the receipt_id is being used instead of the request_id.
The 409 error can happen for a few different reasons: no_drivers_available, missing_payment_method, surge, fare_expired, retry_request, current_trip_exists. Details can be found here - https://developer.uber.com/docs/rides/api/v1-requests
I don't see the different between the two api requests examples you provided. The sandbox will always show a static map.
In production, maps are only available after a ride has been accepted by a driver and is in the accepted state. Attempting to GET this resource before that will result in a 404 not found error. The sandbox environment provides /v1/sandbox/map for testing, but it provides a static map.
Related
I'm developming RESTful API service. I've got disagreement between Me and my Team Lead, on the subject: "HTTP Response status codes".
My Team Lead talks, that default HTTP status codes written in RFC is awful and it's very hard to handle them on the client side(frontend). He thinks that custom status codes in response body, with HTTP status code 200 (every time 200) - the best way. His response body will like following, when trying to execute action without permissions:
HTTP/1.1 200 OK
{
code: 1005, // Custom code instead 403
data: {
message: "Forbidden."
}
}
I think that is wrong way to response. My response scheme will be like this:
HTTP/1.1 403 Forbidden
{
code: 403,
success: false,
message: "Forbidden."
}
Should we use RFC HTTP status codes, or we can use our own custom? Where is the best and right way?
The short
You are absolutely right.
The long answer
In restful API design you have to make use of the official HTTP codes specified in RFC-7231. Please do not send a 200 OK for every request. 200 OK is reserved for requests which actually succeeded and the server responds with a valid state of a particular resource. There are codes for most use cases. If you still need to differ errors of the same type, for example FORBIDDEN you may send a custom error code along. But the HTTP response is still an error therefore you shall not use 200 OK.
Regarding your proposed error scheme, you should not send the code and status within the body. This is already sent as the HTTP status and therefore redundant. Also a boolean success flag is redundant since the type of HTTP code already points out if it was a success or not (2xx => success, 4xx client error, 5xx server error).
The body should contain additional context which will help an API client to resolve the problem.
A well designed API error response should contain helpful information to fix a possible problem:
Request ID which gets generated per request on the server
Detailed error message
(Optional) Internal error code
(Optional) Error category
(Optional) Reference to the api documentation/error description
Example:
HTTP/1.1 403 Forbidden
{
"requestId": "a5e5dd13-0047-4d2e-b96c-55a5031f0511",
"message": "You are not allowed to access this resource. Missing write permission.",
"category": "AccessControl"
}
If this still is not enough for your team lead to believe you may point out some well designed REST API's:
GitHub API v3
Kubernetes API
I am using the REST version of the Here Maps API. It seems that if I provide a destination location (latitude, longitude) that cannot be routed the API is returning a HTTP Error of 400 (Bad Request).
I was under the impression I would get a 200 response code but no data would be returned.
For example if I send a request to the API with New York as the source and Paris, France as the destination the API returns a 400 bad request.
The response codes of RESTful APIs are determined by the API developers. From what you are saying it seems that Here Maps does not know how to route someone over the Atlantic Ocean and is telling you that by returning a 400 Bad Request response instead of providing a 200 response. Http Status Code Explanations
You'll want to dig into the api documentation, perhaps the API is expecting two points that can be routed by land and you can supply a way to indicate that by-air and/or by-sea routes are okay also.
Alternatively, you will need check the response status from the Here Maps API first on your program before you attempt to consume it as a 200 status and if you receive a 400 status then you can communicate that there was an error to your end user which you could inform them of the reasons why a particular request might fail. Such a source and destination on continents not linked by a land mass.
(This reminds me of how Google Maps used to provide driving directions which would tell you to kayak across oceans, not sure if still does that but illustrates a way to resolve a by-land route that cannot be taken only by land.)
I am using PostMan as a REST client to test this API method Cisco ACL Analysis API. specifically POST /acl/trace or getAClTracksStd (first go to Policy Analysis)
Here is my PostMan HTTP test call
Does anyone who is familiar with PostMan understand why I am getting this "Request method 'GET' is not supported" error from the server? I am making a POST HTTP request, not GET.(Selected from Drop down menu) It make more sense for me to get a input invalid parameter error or something.
Just to show that the endpoint url works, heres a HTTP test request that works
(same link, host->host API -> GET /host/{startIndex}/{recordsToReturn}
There's two issues that I'm seeing with your REST call. First, the error you're seeing is because the call needs to be preceded by "https://". Second, remove the interface IDs parameter and values. You should get a response with data after making these changes.
Your json looks erronuous (comma after the destIp) - and the server probably always responds with a default confusing error message in this case. (Postman is very well tested and it sends POST).
I use OAuth 2 in a REST API and I my API returns a 401 error, if my access token is invalid.
My 401 response isn't meaningful right now and I wonder if I could place my authentication URI in my response? Something like
{
"error": 401,
"authentication_uri": "https://example.com/login?client_id=123&response_type=token&redirect_uri=http://example.com/app/"
}
Can I do that? Is this secure? (It seems that all these params are exposed in the URL anyway...) Are there other common methods to get a meaningful response from 401? I couldn't find something useful about this topic.
I am not a security expert, but I don't see a problem with doing this. I'm not aware of any value in hiding how to authenticate, and I don't see you exposing anything that they don't already have (assuming client_id and redirect_uri were in the original request).
To answer my own question: While it is certainly possible to do this and has benefits as you don't need to know the authentication URI beforehand, it has some pitfalls.
Say you develop multiple apps separately at http://localhost and you want to communicate the same REST API. The REST API can't deduce your client_id just from your Referer or Origin header field as it is always http://localhost. You could develop "App 1" or "App 2" and each has a different client_id. Therefor you would need to support URI templates. E.g.:
{
"error": 401,
"authentication_uri": "https://example.com/login?redirect_uri=http://localhost&response_type=token{&client_id}"
}
See here for more examples about URI templates.
I've created a Private App (got the API Key, Password, and Secret) but it's not allowing me access for some reason. I'm issuing the GET request without any parameters... should I be using something in the request? Thanks! Josh
{"response":
"Error message:
GET
https://58b135637023de04edb493880e25XXXX:2d6982192cdc0ea753ba6a729c9dXXXX#ellabing-com.myshopify.com/admin/products.json? returned a response status of 401 Unauthorized
"Server response": {
"errors":"[API] Invalid API key or access token (unrecognized login or wrong password)"
},
"remoteServiceStatus":1,
"success":false
}
Hmm… can you check the request that’s coming from your machine using a web debugging proxy like Charles or Fiddler and see if an Authorization header is really being passed in the request?
The format that https://58b135637023de04edb493880e25XXXX:2d6982192cdc0ea753ba6a729c9dXXXX#ellabing-com.myshopify.com/admin/products.json is in works for browsers and some clients, but is an unofficial shorthand, and not always supported.