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

by Toto   Last Updated October 09, 2019 15:05 PM

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.

Answers 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.

October 09, 2019 14:42 PM

Related Questions

Updated February 13, 2019 14:05 PM

Updated June 12, 2015 15:02 PM

Updated April 24, 2018 08:05 AM

Updated July 14, 2019 06:05 AM

Updated September 11, 2018 10:05 AM