Remove JaxRS dependency about problem

[cbornet]

@whiskeysierra yes, you're right. Switching to int (Integer ?) would probably be the best since only the code is serialized.
Do I PR ?

[cbornet]

I think 2/ is nicer for the end-user since he gets the status code meaning instantly.
As for maintaining the enum, I think it's not a big deal since we can provide the most commonly used statuses and people who use exotic ones can easily add them in their own code (just like what is done in JAX-RS). They will even enjoy the java8 default methods of the interface (which is not the case with JAX-RS).
I'll do the PR based on 2/ then we can discuss on it if you're OK.

[whiskeysierra]

It seems to me that only the Status/StatusType classes are used from JAX-RS.

Correct.

This doesn't represent a lot of code so it would be easy to duplicate. Also, it's always nice to remove a dependency and will make the lib smaller.

Yes, but that would be a breaking change. That would at least require that we also do this change in zalando/problem-spring-web.

[whiskeysierra]

In general I'd be fine with switching from StatusType to int.

[whiskeysierra]

Do I PR ?

It would be highly appreciated!

[cbornet]

Do you prefer Integer (+ static constants) or enum ?

[whiskeysierra]

I think Integer without any static constants should be enough. I don't want to maintain a complete list and enum would be too restricting since it needs to be extensible as dictated by the RFC.

[cbornet]

The reasonPhrase is used in GenericProblems to set the Problem title.
What should I do about it ?

Abou enum extensibility, we can use an interface like StatusType. So users can add there own status enum by implementing it.

[whiskeysierra]

The reasonPhrase is used in GenericProblems to set the Problem title.
What should I do about it ?

Good question. Maintaining a list of status code + reason phrases is equivalent to maintaining a complete status enum itself. Something that I'd like to avoid.

Abou enum extensibility, we can use an interface like StatusType. So users can add there own status enum by implementing it.

Yes, that's true. In fact I used JAX-RS for this very reason. And because it contained an enum already that I didn't have to maintain myself.

I'm torn between the following two options:

1. a simple int (or Integer), no reason phrase, no enum/dictionary of statuses that we need to maintain
2. an interface + an enum of defaults, that introduces a new place where status codes are defined (in addition to JAX-RS, Spring, ...). But you get typed status objects + reason phrases.

I see good arguments for both. Which one do you prefer?

[whiskeysierra]

I'll do the PR based on 2/ then we can discuss on it if you're OK.

Sounds good!