Introduce api.Error type (and improve errors)

[markspolakovs]

This will let downstream consumers handle the different MyRadio response codes differently (for example, 2016-site rendering a 404 when MyRadio sends a 404, rather than a 404 for everything). Intended usage is

something, err := session.DoAThing()
var apiErr api.Error
if errors.As(err, &apiErr) {
  // request succeeded, but MyRadio returned an error
  // do something with apiErr.Status
} else if err != nil {
  // something went wrong with making the request itself
}

[MattWindsor91]

I'm not Michael Grace, but I thought I'd have a quick look while I'm browsing through URY stuff :) it looks mostly good to me, I just had a few questions about things.

[MattWindsor91]

Are there any errors that need to be caught on closing a request body?

[markspolakovs]

https://stackoverflow.com/a/47294087/2586553

There are two things to consider: What would you do with it if you checked it and there was an error? And, what would the side-effects be if there was an error?

In most cases, for closing a response body, the answer to both questions is... absolutely nothing. If there's nothing you'd do if there was an error and the error has no appreciable impact, there's no reason to check it.

[MattWindsor91]

Are there any situations where the response coming back from MyRadio states that it is not OK in the payload but OK in the HTTP status, or vice versa? Am just wondering about the fact that there is now only one check at the response body level and nothing on the HTTP code directly.

(Presumably those would be bugs in MyRadio, mind. It seems kind of weird to have that redundancy, but it's been so long since I looked at MyRadio that I don't even know anymore.)

[markspolakovs]

As far as I can tell, per controllers/api/v2.php any successful response will have "status": "OK" - though the converse isn't guaranteed (there are status values other than FAIL - see MyRadioException).

[MattWindsor91]

I ran into the problem of missing error granularity again while trying to work on 2016-site's podcast handling, so it'd definitely be nice to have.