refactor(http)!: cleanup ApiError

[vilgotf]

It's other variants are outdated, and the message field is covered by the Display impl on Error.

[zeylahellyer]

I'm unsure I understand this PR. Doesn't this remove support for parsing field errors? https://discord.com/developers/docs/reference#error-messages

[vilgotf]

I'm unsure I understand this PR. Doesn't this remove support for parsing field errors? https://discord.com/developers/docs/reference#error-messages

ApiError has three variants:

1. General has a message (String) and error code
2. Ratelimited has a message (String), global (bool) and retry_after (f64)
3. Message has an optional array of embed field errors

Let's analyze these fields. The error message is not something users are supposed to match on, and it's already provided through the Display implementation on Error. The message variant seems completely out of date.

This leaves the JSON error code, global and retry_after.
This PR keeps just global and retry_after in an optional Ratelimit struct, attached to ErrorType::Response. I suppose however that the JSON error code should be preserved too, and I propose that we keep ApiError but scale it down to:

enum ApiError {
    Code(u64),
    Ratelimit(Ratelimit),
}

struct Ratelimit {
    global: bool,
    retry_after: f64,
}

[vilgotf]

Also I dislike the api_error module, so I'll move everything under error

[zeylahellyer]

The message variant seems completely out of date.

In what way is it out of date? If it is, shouldn't we get it up to date? These object and array error messages detailing form body errors are still returned by the API

[vilgotf]

I thought they were replaced/deprecated in API v8, other API error responses are also undocumented which makes it look unsupported to me.
But still this PR only removes the functionality of MessageApiError, which I highly doubt is used for any sort of error handling, especially since it should be handled by twilight-validate.

[zeylahellyer]

I thought they were replaced/deprecated in API v8, other API error responses are also undocumented which makes it look unsupported to me.

Quite the opposite, they were introduced in API v8. If you send this request:

echo '{"embeds": [{"type": "rich"}]}' | http post https://discord.com/api/v10/channels/:id/messages

You'll get this response:

{
    "code": 50035,
    "errors": {
        "embeds": {
            "0": {
                "description": {
                    "_errors": [
                        {
                            "code": "BASE_TYPE_REQUIRED",
                            "message": "This field is required"
                        }
                    ]
                }
            }
        }
    },
    "message": "Invalid Form Body"
}

This response is what the MessageApiError variant attempted to do, perhaps incorrectly. I would rather we fix that than remove it, as it is a documented structure in the API. I can understand if you're not enthusiastic about that, so I can do that if you'd like

[vilgotf]

So is the Array, Object and Response types stable? I.e. {"errors":{"<SOMETHING>":{"N":{"<SOMETHINGELSE>":{"_errors":[{"code":"<CODE>","message":"<MESSAGE>"}]}}}} is the stable representation of Array Errors (for some value of SOMETHING, SOMETHINGELSE, CODE, and MESSAGE and integer N)?

[zeylahellyer]

Triage: deferring research to after 0.15

[vilgotf]

So is the Array, Object and Response types stable? I.e. {"errors":{"<SOMETHING>":{"N":{"<SOMETHINGELSE>":{"_errors":[{"code":"<CODE>","message":"<MESSAGE>"}]}}}} is the stable representation of Array Errors (for some value of SOMETHING, SOMETHINGELSE, CODE, and MESSAGE and integer N)?

This is more or less correct according to Discords OpenAPI spec