1

Using a following API:

feed?url=XXX

Validations performed on the parameter url:

  1. If missing: 400 Bad Request
  2. If empty/invalid URL: 422 Unprocessable Entity
  3. If URL don't point to a valid RSS/Atom feed: 422??

What status error should be returned for the 3.?

Unlike validation 2., it is not possible to check the 3. without fetching data and trying to parse it, so raw user data can't be directly validated.

I was thinking about 422 Unprocessable Entity because it is related to validation even if is not directly the data (url) but the reference of this data (content of the url).

What is your opinion?

Pleymor
  • 2,611
  • 1
  • 32
  • 44
Kakawait
  • 3,929
  • 6
  • 33
  • 60

1 Answers1

0

422 is inappropriate for #2 and #3. It relates to the server understanding the Content-Type header, but the actual content in the HTTP request body could not be interpreted.

I think you could make the argument that 502 Bad Gateway is appropriate here. It's a bit weird because the problem is both user error (incoming url parameter, so a 4xx code), but also it's kind of happening on the server, and in particular an origin server (which makes sense as a 5xx and specifically 502).

But if in this context you strictly consider this an issue that the client caused (bad input in the url) and not server-side, then I would say that there's not a specific enough error code for this, and you should probably just stick to 400 for all of them.

And maybe.. perhaps you can make the argument that 409 might work here. A 409 can used in a case where:

  1. There is nothing in particular wrong with the HTTP request perse.
  2. But the state of another resource is causing the request to fail.

Typically that 'other resource' lives in the same system, but I don't see why the external Atom feed could also not be considered as conflicting.

Because if the Atom feed on the external server is 'fixed', then the original HTTP request that the user made will now work. So a 409 kind of is appropriate here.

Evert
  • 93,428
  • 18
  • 118
  • 189
  • About `422` I'm agree that query parameter is not part of *entity* so it could be hard to return *Unprocessable Entity*. But I don't really think `409 Conflict` is a better alternative (from what I read here https://tools.ietf.org/html/rfc7231#page-60). – Kakawait May 31 '16 at 07:47
  • My experience with 409 and how it's used stems from it's usage in WebDAV (a HTTP extension). There the way it's applied it means almost universally "the request is not wrong, and it might succeed if sent again after the state of a different resource has changed". This is also definitely how I would interpret 409 from the HTTP extension, even if it's a bit more general and cryptic there. – Evert May 31 '16 at 14:12