An empty response can be a valid response

[gregsochanik]

Currently we treat ALL empty responses as a NonXmlResponseException i.e.

if (string.IsNullOrEmpty(response.Body))
       throw new NonXmlResponseException(response);

There is a use case where an empty response can be returned, for example using POST to create a new resource can return a 201 Created along with a Location header directing you to the Url of the newly created resource.

One problem is that at the moment, the Api returns 200 for a 201 so we can't check for that, but we can check for an empty response and the Location header

Therefore I think we should allow a check before passing the response off the the ResponseParser which checks for an empty response and the Location header. If the Location header exists, skip the de-serialization attempt.

This does leave one issue, i.e. what do we return as the typed "response"? Should we allow another method that returns just the raw response, and let Please() do the de-seralization?

e.g.

Response response = new FluentApi<Track>()
                .ForTrackId(12345)
                .Response();

vs

Track track = new FluentApi<Track>()
                .ForTrackId(12345)
                .Please();

If we do this, we can at least then allow the consumer to decide whether they want to let the wrapper handle everything, or they want to leap in and parse the response manually (i.e. to check response header values etc)

[gregsochanik]

PR to follow shortly....

[gregsochanik]

Closing as allowing access to Response prior to de-serialization effectively solves this.