If you run an API server then a client sends a bad request, you would usually send him 400 Bad Request error but is it acceptable if you change the message to a more specific one?
Example:
400 Invalid ID
400 Parameter x, y, z is required
400 Minimum length for parameter is x
The canonical place for additional information would be the response body.
There is precedent for using your own codes (which can be handy for log file analysis), but there is nothing wrong with putting whatever description you like in the response.
Related
I'm trying to understand which Http Status Code to use in the following use case
The user tries to do a GET on an endpoint with an input ID.
The requested data is not available in the database.
Should the service send back:
404 - Not Found
As the data is NOT FOUND in the database
400 - Bad Request
As the data in the input request is not valid or present in the db
200 - OK with null response
200 - OK with an error message
In this case we can use a standard error message, with a contract that spans across all the 200 OK responses (like below).
BaseResponse {
Errors [{
Message: "Data Not Found"
}],
Response: null
}
Which is the right (or standard) approach to follow?
Thanks in advance.
Which is the right (or standard) approach to follow?
If you are following the REST API Architecture, you should follow these guidelines:
400 The request could not be understood by the server due to incorrect syntax. The client SHOULD NOT repeat the request without modifications.
It means that you received a bad request data, like an ID in alphanumeric format when you want only numeric IDs. Typically it refers to bad input formats or security checks (like an input array with a maxLength)
404 The server can not find the requested resource.
The ID format is valid and you can't find the resource in the data source.
If you don't follow any standard architecture, you should define how you want to manage these cases and share your thought with the team and customers.
In many legacy applications, an HTTP status 200 with errors field is very common since very-old clients were not so good to manage errors.
I am building an API about email auth code.
Its process is simple.
input random code (client browser)
request with input code. (client browser)
receive the request (server)
scan the code from DB (server)
there is no code matched (server)
return a response with status code.
There are many status code, (2xx, 4xx, 5xx);
but I don't know which status code number is the most proper for this case.
It depends on the semantics you want to give your request. E.g.:
The API should search for items matching the query and return a list of results, like GET /codes?q=4ba69g. Think a "search page". In this case, an empty result [] is a perfectly valid result; nothing was wrong with the query, it just didn't return any matches. That's a 200 OK, or maybe a 204 No Content if you want to omit the empty response body entirely.
The code is treated like a resource, e.g. GET /codes/4ba69g. In this case a missing code would result in a 404 Not Found.
It's an action you want to perform which may fail, e.g. POST /login. If the user supplied the wrong credentials/code and hence the action cannot complete, that's a client-side error and therefore a 400 Bad Request.
Say for example, I created a flow for scatter-gather and I want to check if all endpoints are returning same result status code 200 or throw an error if not.
Configure the Response Validator (General > Response > Response Validator) for each HTTP Request so only 200..299 responses are considered valid.
You can use try block for every HTTP request on wrap whole scatter gather. If one fails, capture HTTP status code in on error propogate and log the results.
I suggest you wrap each request into try block, if you already have a global error handler defined, it should pick up status code 500 etc. Otherwise, capture response code into dataweave
A parse server cloud function is defined via
Parse.Cloud.define("hello", function(request, response) {..});
on the response, I can call response.success(X) and response.error(Y), and that sets the http response code and the body of the response.
But how do I define a different code, like created (201)?
And how do I set the headers of the response?
thanks, Tim
You are allowed to return any valid JSON from response.success(). Therefore, you could create an object with fields such as code, message, and value, so you can set the code, give it a string descriptor, and pass back the value you normally would, if there is one. This seems to accomplish what you need, though you will have to keep track of those codes across your platforms. I recommend looking up standard http response codes and make sure you don't overlap with any standards.
For some push messages sent using MPNS I am getting a response with the following values:
statusCode = 200
notificationStatus = Dropped
deviceConnectionStatus = Connected
subscriptionStatus = Active
Looking at the only documentation I found it seems the meaning of this particular combination is not explained:
https://msdn.microsoft.com/library/windows/apps/ff941100(v=vs.105).aspx
What I want to know is if I should treat this as an error and if so, should I retry later or just give up?
Even if we cannot find a specific documentation to check the particular combination you provide, we can still analyze it based on our common experience:
200 OK means your request has been received successfully
Dropped means the MPNS has not received your request normally
Connected refers to your device status when the request is sent
The last header returns if the channel is still valid(Active) or not(Expired)
Thus, I think you can retry later since your channel is still valid.