Response.Status does not include '422 unprocessable entity'

[Ziaunys]

I noticed that the status enum doesn't contain an entry for the 422 status code.
I see that there's an path for adding codes that aren't in the enum by implementing StatusType so that's probably the best option for now. Perhaps it could be added in the future? I don't know what criteria is used to determine which codes go in there or if it's just arbitrary. Thanks.

[mkarg]

JAX-RS is not a complete product, but just an extensible framework that comes with foundational base work. Adding new numbers to that base only makes sense if a lot of users (possibly all) need to use that number in a frequent cadence. Otherwise you can simply implement StatusType and publish it as a standalone open source library if you see a need for many (but not lots) of users. An example is to be found here: https://gitlab.com/headcrashing/webdav-jaxrs/-/blob/master/src/main/java/net/java/dev/webdav/jaxrs/ResponseStatus.java. We invented StatusType exactly for such edge cases where a specific set of status codes is bound to a specific use case or technology (like WebDAV). Anecode: It was exactly that particular piece of code (jaxrs-webdav) that made me invent that particular interface and proposed it for adoption to JAX-RS 1.1.

[jansupol]

I can see RFC 9110 containing the status codes.

• Quarkus contains the 422 status code.

• Helidon does not contain status 422.

• Micronaut contains the status code 422.

• Spring contains the http status code 422.

It looks like the industry (but Helidon) contains all the status codes available. I understand the StatusType to be more of a support for cases when Status is not available when the API was created, but is available when the API is used. For 4.0, I think it makes sense to implement the status codes in the HTTP RFC.

[mkarg]

I have nothing against it if all vendors agree to do so. Nevertheless, I have not seen any single application making active use of it, so I still doubt the general benefit.

In fact, the sole cause why I invented the StatusType interface more than a decade ago was explicitly the possibility to provide modularity in this area, but nothing else.

[spericas]

I don't see a strong reason not to add them. @Ziaunys Are you interested in contributing a PR?

[chkal]

Please also see the discussion here: https://github.com/jakartaee/rest/issues/1147#issuecomment-1565395466