Current behavior on sandbox:
Create ride request (drivers available)
While status is processing, set drivers not available
Ride request status changes to no_drivers_available as expected
Set drivers back to available
Previous ride request is back to processing
I would be expecting the request to not go back to processing and rather stay on no_drivers_available. Is this a bug or is that your defined behavior? If so, could you provide more explanation?
If there is valid ride request with "processing" status - and product that was used to create this request was modified and set drivers_available to false, ride requests will terminate with the status "no_drivers_available". If product gets modified again and set drivers_available to true - ride request status will change to "processing" again - and closest available driver will be able to accept this request. So there is no "bug" in this flow - and this is expected behavior.
Related
I need you to help me to decide what HTTP status code I should use.
I have data that I want to modify with a PUT request. This data have different states possible:
draft, toConfirm,confirmed,refuse etc.
I want to allow the modification only if the data's state is draft or toConfirm.
I would like to know which HTTP status code should I use if the date's state is neither draft or toConfirm? 400 for Bad Request ? 405 Method not allowed? 418?
Thank you very much.
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource.
405 Method Not Allowed would also be fine.
I'm developing an API for events management. I have the basic GET and POST methods but now I have to deal with the event resource edition.
A user can edit all the event information using:
PUT /event/:eventId
But also it can cancel the event (not deleting it, but changing it's status property).
I've thinking on using this endpoint:
PATCH /event/:eventId and send a body with only the new status property value.
I think this is a good approach but then I have noticed that the status can only be set to CANCELLED, the other allowed status for the event are changed automatically in the business logic in certain cases.
So sending the status field doesn't make sense at all if you only can change it to one possible value.
Therefore, is it possible and not a bad practice to send no body to a PATCH method? Thanks.
I would suggest to make PATCH endpoint to /event/{eventId}/status.
There is no need to put payload to your PATCH request, payload is optional.
API should be meaningful to end user. With PATCH you are letting user know that you want to do a partial update on the event record for provided eventId and the attribute you want to perform action is status.
In addition, make sure your API doc provides the detail that status will be set to CANCELLED by default. And in future, if required you can scale API by adding payload {"status": "CANCELLED | ENABLED | .." }
I would suggest to add payload to body of PATCH /event/:eventId.
If in any case you need to add a new attribute for updating an event's attribute, you will not be able to decide if you need to update the status or not. This can future proof your endpoint.
I am performing a POST to a resource URI. But the success of this operation depends on the responsiveness or accessibility of another related object. If that object is not responsive or inaccessible, the operation needs to return failure. What HTTP code should I choose in this case?
I am currently brainstorming on the following codes, but could not arrive at the right one:
404 NOT FOUND - This represents "not found" for the resource URI, and not a related inaccessible entity.
412 PRECONDITION FAILED - Applicable only for conditional requests with one or more header fields indicating a precondition - I dont need to provide any.
I am not able to find or zero onto a specific HTTP code.
https://greenbytes.de/tech/webdav/rfc7231.html#status.409:
"6.5.8 409 Conflict
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict."
Lets check the candidates:
404: always an option but as the same request will sometimes fail or success this will create a flickering behavior which is not what a client would expect when getting 404.
412: RFC 2616 says: "The precondition given in one or more of the request-header fields" - this is not the reason for the failure.
417: similar to 412: "The expectation given in an Expect request-header field could not be met by this server"
503: "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server."
Nothing seems to be perfect but I would choose 503 as it represents the temporary problem best and guides the client to do a retry.
Picking the right status code is always tricky. If you return a status code like 404 for example, debugging can become derailed because someone may not be sure if it's because the URL actually doesn't exist or if it's because of some other reason internally.
Usually the caller only needs to know a few things:
Did the endpoint exist? If not, 404 NOT FOUND
Was my request properly formed and did it pass validation? If not, 400 BAD REQUEST
Was my request denied because of improper authentication? If not, 401 or 403 depending on the context (there is a subtle difference)
Did my request fail because of something out of my control? If so, 500 INTERNAL ERROR
Typically I try to separate the response from the service's logic. If you want to be more specific as to exactly what happened (in your example a dependency is not responsive), returning a bit of JSON that describes in more detail what the problem was is would be a more appropriate place for that as opposed to using the http status code to describe a specific error on the service side.
So in your case, I think 500 is the most appropriate. The caller just knows that something went wrong and there's nothing it can do about it, and it can handle that condition however it needs to. If the caller needs to know more about what happened, use a JSON response to convey that.
List of HTTP status codes
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
Refer wiki :
103 Checkpoint
Used in the resumable requests proposal to resume aborted PUT or POST requests.
420 Method Failure (Spring Framework)
A deprecated response used by the Spring Framework when a method has failed.
420 Enhance Your Calm (Twitter)
Returned by version 1 of the Twitter Search and Trends API when the client is being rate limited; versions 1.1 and later use the 429 Too Many Requests response code instead.
450 Blocked by Windows Parental Controls (Microsoft)
A Microsoft extension. This error is given when Windows Parental Controls are turned on and are blocking access to the given webpage.
498 Invalid Token (Esri)
Returned by ArcGIS for Server. A code of 498 indicates an expired or otherwise invalid token.
499 Token Required (Esri)
Returned by ArcGIS for Server. A code of 499 indicates that a token is required but was not submitted.
499 Request has been forbidden by antivirus
Produced by some programs such as Wget when a malicious site is intercepted.
509 Bandwidth Limit Exceeded (Apache Web Server/cPanel)
The server has exceeded the bandwidth specified by the server administrator; > this is often used by shared hosting providers to limit the bandwidth of customers.
530 Site is frozen
Used by the Pantheon web platform to indicate a site that has been frozen due to inactivity.
In proper usage of REST, what is suitable the HTTP status code when request is successful but has warning messages?
In our case; clients are web applications running on browsers. We prefer status codes as following:
HTTP 200, 201, 204 when request processed successfully
HTTP 422 when request violates some business rules
HTTP 500 when unexpected exceptions are occured while processing request
But we couldn't determine which status code should be used when request processed successfully but some information or warning messages need to send to client?
In the HTTP protocol there actually is a "warning" header (see Header Field Definitions ).
These are HTTP warnings, but you could use code 199 to send what you need:
199 Miscellaneous warning The warning text MAY include arbitrary
information to be presented to a human user, or logged.
The problem here is the next bit of specification:
A system receiving this warning MUST NOT take any automated action, besides
presenting the warning to the user.
Because of this, I think you're better off adding data about the warning in the response content (and keep using the 200 status code).
HTTP status codes are determine whether the request has been proceed properly or not and there is no warning status. If you want to provide information about result of your internal functions you should add information status to the response content eg:
{
status: "WARNING",
code: "WARNING-CODE"
}
In a similar case I used HTTP 418 (see HTCPCP)
The clients were web apps using the Google Maps API to display map tiles. And I wanted to make a distinction between a deliberately blank tile (zero data -> blank tile with HTTP 200) and a blank tile resulting from missing data (null data -> blank tile with HTTP 418).
Returning a 404 precluded me from sending a tile in a response body, and would place ugly symbols on the map. But returning a 418 still allows a response body (perhaps due to lack of serious standards definitions surrounding HTTP 418?), AND at the same time provided a status code that I could easily filter in the logs, etc. to use for diagnostic purposes.
I have a request from the client - when the user performs an action, there can be 3 actions:
the action succeeds with 200 OK status
the action fails (400) with an error message
the action succeeds but we need to display a helpful warning message to the user. This happens when the allocated amount is almost used up.
There does not seem to be a way for REST APIs to return an indication that the action completed successfully with some helpful information that further action might fail.
Thanks
HTTP response codes are limited and I think, those to be used to indicate any generic response. To have application specific response codes or response strings, it is better to have application level response codes to be communicated via HTTP response payload.
You didn't mention which HTTP method you are preparing for. Using GET should of course not modify anything, so I'm assuming it's either POST or PUT.
For POST, the response should be 201 Created. There should be a Location header line indicating the resource that was created.
For PUT, the response should be 200 OK.
In both cases, you can return a content body, as others suggested. This body can be some status information about the current state of whatever resource you are using. Note, that this status information might be reachable explicitly by some other URI, so it can share a mime-type with that "status" resource.
REST is using HTTP methods and HTTP status to represent the status of reply, by checking HTTP status I can find code 203 I think it could be suitable for your 3rd case :
203 Non-Authoritative Information (since HTTP/1.1)
The server successfully processed the request, but is returning information that may be from another source.