Idea Symbolic Names for HTTP Status codes

[zkessin]

I had a thought, currently to express a http status code you have to remember the number, would it be possible to have a named type for them. So instead of having the number 304 in my code I could ahve the value 'NotModified' which esp for some of the more unusual status codes would be very helpful in making code more readable.

For example if I see that something should return 415 I probably will have to look up what that means but if I see UnsupportedMediaType it is self documenting.

[jkarni]

I'm in favor of descriptive alternative names for all the err* ServantErrs. Do you want to send a PR?

[zkessin]

i can work on it, but not in the next two weeks. I am giving a talk next week at a user group and am trying to finish a book, but if no one else has done it by mid nov I may give it a shot

[fizruk]

I suggest we add type and function synonyms for existing Nats and err*s. E.g.:

type OK = 200
type Created = 201
type BadRequest = 400
...

badRequest = err400
notImplemented = err501
...

However I think this should be done in a separate module (e.g. Servant.API.HttpCode and Servant.Server.HttpErrorCode) and not imported by default since it introduces a lot of names that might interfere with user's code. Alternatively we could use prefixes for those names, but I find it less nice.

[zkessin]

I would call it HttpStatusCodes not HttpErrorCode, as not all of them are errors. But otherwise @fizruk presents a good solution

[jkarni]

Do we need the type synonyms for Symbols? Where does the user come across them?

[fizruk]

@zkessin I assumed that for server handlers one only needs error codes, because regular status codes are mentioned in the API (well, exactly one is).

[zkessin]

I like completeness, the other webframework of choice is WebMachine on Erlang. But yea, you might want to do a 304 or a 415 etc

https://raw.githubusercontent.com/wiki/webmachine/webmachine/images/http-headers-status-v3.png

[fizruk]

@jkarni I think you meant for Nats. User faces those when she/he has to define a custom Verb, not listed already in Servant.API.Types. I am not entirely sure that we need those synonyms, but a module with those may at least serve as an explicit list of HTTP status codes with their description.

[dredozubov]

@fizruk set of permitted HTTP codes is finite, therefore some explicit listing looks like a good idea anyway