Databases
StackOverflow2013
Postsdbo
POHTTP status code in REST API for using GET to query a “Not Ready Yet, Try Again Later” resource?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHTTP status code in REST API for using GET to query a “Not Ready Yet, Try Again Later” resource?
    primarykey
    data
    text
    <p>First of all, I've read some relevant posts:</p> <ul> <li><a href="https://stackoverflow.com/questions/9794696/best-http-status-code-in-rest-api-for-not-ready-yet-try-again-later">Best HTTP status code in REST API for “Not Ready Yet, Try Again Later”?</a> It is about GET an item</li> <li><a href="https://stackoverflow.com/questions/4099869/is-it-wrong-to-return-202-accepted-in-response-to-http-get">Is it wrong to return 202 “Accepted” in response to HTTP GET?</a> It is about GET an item</li> <li><a href="https://stackoverflow.com/questions/11080197/http-status-code-for-resource-not-yet-available">HTTP Status Code for Resource not yet available</a> It is about POST</li> <li><a href="https://stackoverflow.com/questions/13653850/http-status-code-for-in-progress">HTTP status code for in progress?</a> It is about GET but no clear answer.</li> </ul> <p>but I still think I should raise my question and my thoughts here. What should be the HTTP status code in REST API for using GET to QUERY a “Not Ready Yet, Try Again Later” resource? For example, client tries to query all local news happen in future(!) by make an HTTP GET to this url: <a href="http://example.com/news?city=chicago&amp;date=2099-12-31" rel="nofollow noreferrer">http://example.com/news?city=chicago&amp;date=2099-12-31</a> so what shall the server reply?</p> <p>These are the http status code I considered, their rfc definition and why I am not fully satisfied with:</p> <ul> <li><p>3xx Redirection. <strong>Comment</strong>: Not an option because there is no other link to be redirected to.</p></li> <li><p>503 Service Unavailable: The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. <strong>Comment</strong>: The retry behavior is desired, but semantically the situation is not server's fault at all, so all 5xx look weird.</p></li> <li><p>4xx Client Error. <strong>Comment</strong>: Looks promising. See below.</p></li> <li><p>413 Request Entity Too Large: The server is refusing to process a request because the request entity is larger than the server is willing or able to process. ... If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. <strong>Comment</strong>: The retry behavior is desired, however the "Entity Too Large" part is somewhat misleading.</p></li> <li><p>417 Expectation Failed: The expectation given in an Expect request-header field (see section 14.20) could not be met by this server. <strong>Comment</strong>: So it should be caused by an Expect request-header, not applicable to my case.</p></li> <li><p>406 Not Acceptable: The resource ... not acceptable according to the accept headers sent in the request. <strong>Comment</strong>: so it is caused by the Accept request-header, not applicable to my case.</p></li> <li><p>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 might be able to resolve the conflict and resubmit the request. ... Conflicts are most likely to occur in response to a PUT request. <strong>Comment</strong>: This one is close. Although my case is not about PUT, and isn't actually caused by conflict.</p></li> <li><p>404 Not Found: The server has not found anything matching the Request-URI. <strong>Comment</strong>: Technically, my url path (<a href="http://example.com/news" rel="nofollow noreferrer">http://example.com/news</a>) DOES exist, it is the parameters causing problems. In this case, returning an empty collection instead of a 404, is probably more appropriate.</p></li> <li><p>403 Forbidden: The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. <strong>Comment</strong>: Generally this is supposed to be used in any restricted resource?</p></li> <li><p>400 Bad Request: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications. <strong>Comment</strong>: It is not true in my case. My server understands the request, its syntax is good, only the meaning is bad.</p></li> <li><p>2xx Successful. <strong>Comment</strong>: If 4xx doesn't work, how about 2xx? See below.</p></li> <li><p>200 OK. <strong>Comment</strong>: Fine. So what should I include in the response body? 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 differentiate the minor "future news" error from the more common "all query criteria are good, just no news this day" situation.</p></li> <li><p>202 Accepted: The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon. <strong>Comment</strong>: Providing that we can use 202 in a GET request, it is acceptable. Then refer to the 200 comment.</p></li> <li><p>204 No Content: The server has fulfilled the request but does not need to return an entity-body. <strong>Comment</strong>: Providing that we can use 204 in a GET request, it is acceptable. Just don't know whether this is better than 202 or 200.</p></li> <li><p>More on 2xx: <strong>Comment</strong>: I assume all 2xx response will likely be cached somewhere. But in my case, if I return an empty body for "tomorrow's news", I don't want it to be cached. Ok, explicitly specify the "no cache" headers should help. </p></li> </ul> <p>Your thoughts?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USRayLuo
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COWell, it is a matter of personal opinion in the end. Think I would prefer 200 OK with whatever body template you have chosen with an empty news entry, as there of course are no news to retrieve.
      singulars
      1. POHTTP status code in REST API for using GET to query a “Not Ready Yet, Try Again Later” resource?
      1. UScYrixmorten
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload