0

The use case:

There is a REST resource that is available and reachable but initially can not provide any data. After a certain time, the resource delivers data.

What is REST the right response for this case?

Proposal 1:

Always 200 response code deliver once with empty body {} and once data with body content

Proposal 2:

First 204/202 and then 200 if data is available

But is it a good style to return 2 different 2xx codes on the same resource?

Ganesa Vijayakumar
  • 2,422
  • 5
  • 28
  • 41
MelleD
  • 657
  • 1
  • 9
  • 23
  • Have a look at - https://stackoverflow.com/questions/11746894/what-is-the-proper-rest-response-code-for-a-valid-request-but-an-empty-data. Based on what's explained here, responding with `202` is fitting. – Mo A Nov 29 '19 at 12:37
  • This question surely requires some update to state whether the initial, empty state is a normal/expected state or more related to a failure or non-availability of a background service. In the case of a [POST-PUT creation pattern](http://restalk-patterns.org/post-put.html) returning `200 OK` after the initial creation is fine while in case the empty-state is caused by a non-available backing service a `503 Service Unavailable` is more appropriate, as suggested by @Evert. – Roman Vottner Nov 29 '19 at 19:16

1 Answers1

0

If you are doing GET requests on this resource, and at some points there is no data available and others there is, I don't think 202 or 204 is right.

202 really means that the request has been received and may be processed successfully later, and 204 can be interpreted as 'the request was successful but there's no response bodyordon't change the UI state` if you're building more of a hypertext-style application.

In your description, it sounds more like you're doing a GET request to retrieve the current state, but it's not always available. It's hard to know based on your question why that might be the case, but to me it sounds like you don't want to communicate the state of the resource is actually empty, but more-so that technical issues prevent you from returning the true state back to the user.

It also sounds like there was nothing wrong with the actual request, so this makes 4xx responses inappropriate.

This to me makes me feel that a more appropriate response is 503 or 502. In either case it suggests that the service is temporarily incapable of returning a response, but in either case it might tell a client that it could try again later to see if things improved. 503 in particular has a Retry-After header, indicating to the client that it should try again after a specified amount of time.

Evert
  • 93,428
  • 18
  • 118
  • 189