All geek questions in one place

The HTTP status code in the REST API to use GET to request the "Not ready yet, try again later" resource?

First of all, I read some relevant posts:

but I still think that I should raise my question and my thoughts here. What should be the HTTP status code in the REST API to use the GET for the QUERY resource "Not ready yet, try again later"? For example, a client tries to request all local news in the future (!) By making an HTTP GET for this URL: http://example.com/news?city=chicago&date=2099-12-31 so that the server responds?

This is the http status code I reviewed, their definition of rfc and why I am not completely satisfied:

  • 3xx Redirection. Comment Not an option because there is no other redirect link.

  • 503 Service Unavailable: the server is currently unable to process the request due to temporary overload or server maintenance. It is understood that this is a temporary condition that will be mitigated after some delay. If known, the delay length MAY be indicated in the Retry-After header. Comment : retry behavior is desirable, but semantically the situation is not a server error, so all 5xx look weird.

  • 4xx client error. Comment It looks promising. See below.

  • 413 Request Entity Too Large: the server refuses to process the request because the request object is larger than the server is ready or able to process .... If the condition is temporary, the server MUST include a Retry-After header field to indicate that it is temporary and through what time the client MAY try again. Commentary : repeated behavior is required, but the Essence Too large part is somewhat misleading.

  • 417 Expectation Failed: The wait specified in the Expect request header field (see section 14.20) cannot be performed by this server. Comment Therefore, it should be called by the Expect request header, not applicable to my case.

  • 406 Not valid: resource ... not acceptable according to accept headers sent in the request. Comment : therefore, it is called by the Accept request header, not applicable to my case.

  • 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 will be able to resolve the conflict and resubmit the request .... Conflicts most often occur in response to a PUT request. Comment This object is close. Although my case is not about PUT and is not really caused by conflict.

  • 404 Not Found: the server did not find anything that matched the Request-URI. Comment Technically, my path to the URL ( http://example.com/news ) Exists; these are the parameters causing the problems. In this case, returning an empty collection instead of 404 is probably more appropriate.

  • 403 Forbidden: the server understood the request, but refuses to fulfill it. Authorization will not help, and the request MUST NOT be repeated. Comment As a rule, is this supposed to be used in any limited resource?

  • 400 Bad Request: the request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request unchanged. Comment In my case this is not true. My server understands the request, its syntax is good, only the value is bad.

  • 2xx Successfully. Comment : If 4xx does not work, how about 2xx? See below.

  • 200 OK. Comment : Good. So what should I include in the response agency? null or [] or {} or {"date": "2099-12-31", "content_list": null} or ... which one is more intuitive? On the other hand, I prefer a way to clearly distinguish between the minor error of "future news" from the more common "all query criteria - this is good, not news on this day."

  • 202 Accepted: The request has been accepted for processing, but processing has not yet been completed. The request may or may not be subsequently applied. Comment Giving us the ability to use 202 in a GET request is acceptable. Then refer to comment 200.

  • 204 No content: the server has completed the request, but it does not need to return the body of the entity. Comment If we can use 204 in a GET request, this is acceptable. I just don't know if it's better than 202 or 200.

  • Read more about 2xx: Comment . I assume that the entire 2xx answer will most likely be cached. But in my case, if I return the empty body for tomorrow's news, I do not want it to be cached. Well, I explicitly point out that the "no cache" headers should help.

Your thoughts?

+6
source share
2 answers

You get news for this day, which is a valid day, just no news. The reaction of an empty body 200, or what ever makes sense based on a media type, would seem logical. It depends on the type of media that you decide with the client.

404 will make more sense if the date format was incorrect (you requested on November 45th or asked for a city that does not exist).

Aside, the URL will be better in the format http://example.com/news/chicago/2099-12-31 , as this is the specific resource you want to get. This format could make things like 404s clearer as well.

+1
source

Use 404.

Your objection to this is based on the popular understanding of URIs, as it does not include a request. "Since I have several URIs that map to the same handler, the logic goes, my resource really exists and is simply parameterized with querystring arguments.

This is not true. Since the URI specification itself says in section 3.3 (emphasis mine),

"The path component contains data, usually organized in a hierarchical form, which, together with the data in a non-hierarchical query component (section 3.4), serves to determine the resource within the scope of the URI scheme and naming authority (if any).

Resources are identified by a URI, and any change to any part of an absolute URI identifies a single resource. Tweet it to everyone you know once a day until they tell you to stop. Therefore, 404 is ideal: "The 404 status code (not found) indicates that the source server did not find the current view for the purpose of the resource or does not want to disclose that it exists."

+4
source

Source: https://habr.com/ru/post/956147/

More articles:


All Articles