Does it make sense to qualify an error as an HTTP error without an HTTP client-server communication

Question

I am writing a C# client SDK to a REST Api. This SDK sends JSON-serialized models to the API, and implements a first level of verification of the parameters. If the verification fails, it throws an exception.

An example would be:

if (requiredParameter == null)
{
    throw new ApiException(400, "Missing required parameter");
}

As you can see, ApiException takes an integer as parameter which represents an HTTP error code (in that context "Bad Request"). I'm not sure HTTP codes are semantically meant to be used when there is no HTTP exchange being done between the client and the server (even though in that context going further would result in a 400 error code being replied by the server).

I would love to have some thoughts on this matter.

Answer 1

This does seem odd, but I guess I can't be surprised these days where everyone thinks in terms of RESTfulness

I would expect the client to hide the underlying implementation, not fake expose it.

So if a parameter is missing throw a standard ArgumentException or have some custom validation method that you have to call before sending.

If the server returns a HTTP response code, intercept that, parse it and if it's part of a restful response translate into an appropriate error.

Only if its a legitimate error with the HTTP communication would I expect a HttpException to be thrown with a HTTP error code.