Is it acceptable to use Http status codes (.NET HttpStatusCode enum) in my application instead of creating a new enum ? I encoutered an issue (design issue?) in my API, for example in the authentication process, I had this method signature:public bool authenticate(string token)Leaving me with a Yes/No possibility, where I needed, in the end a Maybe case (But that's unecessary details), so I decided to create a new object with an HttpStatusCode and a string to describe the reason for the status, instead of creating/maintaining a new error code enumpublic class ReturnCode {    public HttpStatusCode code;    public string reason;}Then the status helped me handling 401 and 403's like differences.I get it might be a duplicate of : Should I use HTTP status codes to describe application level eventsBut I don't think the protocol part of the answer is of my concerns as I might not even return (the same) errors to the website (Or maybe I don't understand the answer as I'm not native english speaker).
Is it relevant to use Http Error Code within my Application
.net;api;http
HTTP status codes are useful for returning the status of a requested action.  A web server is usually the thing that handles the request for an action.  If you need to handle HTTP requests like a typical web server does, then it is reasonable to return an appropriate HTTP status code as part of the response to a request.If you are only using these status codes inside your application, and not returning them as part of a response to an HTTP request, then you should use whatever types of status codes you need to satisfy your users' needs.  If the current list of HTTP status codes make your source code better in some way, then use them.  If they do not meet the needs of your users, then use something else.