• @atheken
    link
    3
    edit-2
    11 months ago

    I quickly skimmed this, and it looks kinda overwrought to me.

    This is the format I’ve been using:

    {
    success: bool
    error_code: number,
    message: “human-centric error message”,
    context:  { optional, user-defined details }
    }
    
    • @lysdexicOP
      link
      English
      2
      edit-2
      11 months ago

      Your format looks half baked and not thought all he way through. Take for instance the success bool. What info does this add that error_code and the request’s own status code doesn’t already send? And what’s the point of context if it is both unspecified and optional?

      • @atheken
        link
        2
        edit-2
        11 months ago

        Context is whatever makes sense to provide to a consumer to help them debug it or respond to it - the same basic idea as in the rfc under details. IMO, it can’t easily be generalized. Some APIs may have context to provide, others may not. These could be validation errors in a structured format, or backoff timings in the case of a 429.

        Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

        Consider something like:if(!obj.error_code){} vs if(obj.success){ }. Certainly, you could consolidate the error_code and success member, but with the sloppy truthiness of testing in Javascript, including something like that as a standard part of all responses may make sense.

        • @lysdexicOP
          link
          English
          0
          edit-2
          11 months ago

          No> Context is whatever makes sense to provide to a consumer to help them debug it or respond to it

          So it’s both optional and unspecified. This means it can’t be parsed or relied upon, specially by consumers. It’s useless.

          the same basic idea as in the rfc under details.

          No, it isn’t. Contrary to your ad-hoc format, RFC9457 specifies exactly the data type of detail and what’s its purpose. This allows third parties to reliably consume resources that comply with RFC9457 while your ad-hoc format leaves clients no option other than to ignore it.

          IMO, it can’t easily be generalized. Some APIs may have context to provide, others may not.

          It matters nothing what services can produce. What matters is whether clients can consume it. Your ad-hoc format fails to specify this field, which is optional, and thus leaves no option other than to ignore it. It’s unusable.

          Success is something that you can sniff for after deserializing, as IIRC Fetch API will not throw except for a network errors, even in the event of a 4XX or 5XX.

          What the Fetch API does or does not do is irrelevant. The responsibility of putting together a response and generating the resource shipped with it lies exclusicely in your service. If it outputs a resource that is unable to tell clients what went on, that’s a problem cause by both how your service is designed and the ad-hoc format it outputs.

          The main take is that RFC9457 is well specified and covers basic usecases, while your ad-hoc format is broken by design. Thus when you describe the RFC as “overwrought”, you’re actually expressing the half-baked approach you took.

          • @atheken
            link
            2
            edit-2
            11 months ago

            Sorry, I didn’t mean to reference the detail member, I meant “extension members” as defined in the RFC.

            In the RFC, they are outlined as top-level elements. In the version I proposed, these are bundled up inside of an optional context member. This can be useful in making the serialization and deserialization process a little bit easier to implement in languages that support generics without the need to subclass for the common elements. The RFC specifically defines “extension members” as optional. The key difference is that in what I was describing, they’d be bundled into one object, rather than being siblings of the top-level response.

            It also side-steps any future top-level reserved keyword collisions by keeping “user-defined” members a separate box.

            You seem to be laboring under the notion that this spec produces something that can be entirely negotiated by generic clients, but I don’t see that at all. Even for “trivial” examples (multiple validation errors, or rate-limiting thottling), clients would need to implement specialized handlers, which is only vaguely touched upon by the need to have a “problem registry”.

            And, like it or not, considering how easy or messy it is for a downstream client to consume a result is actually an important part of API design. I don’t see how considering the browser, javascript, and the Fetch API behavior aren’t relevent considerations when we’re talking about extending HTTP with JSON responses.

            Did you author this RFC? I don’t exactly understand why you seem to be taking the criticism personally.

          • @atheken
            link
            111 months ago

            deleted by creator

      • TehPers
        link
        fedilink
        English
        1
        edit-2
        11 months ago

        If both success and error responses include the success field, then that can be a common discriminator between bodies of successful responses and bodies of error responses. Where this adds value beyond the request’s status code, I’m not sure. Maybe it’s useful in aggregated responses where partial successes are allowed (like POSTing a batch of objects)?

        Your format looks half baked and not thought all he way the way through.

        This does seem a bit heavily worded. There’s likely a reason they originally chose and continue to use that format, and it could be as simple as “all our other APIs use this format” or similar. There’s more to choosing a response schema than what is theoretically the most efficient way of communicating the information.

        • @atheken
          link
          2
          edit-2
          11 months ago

          Thanks, and you are basically correct on both counts:

          • I supported an API that had a Batch endpoint that could be “partial success” – and that was a mess.
          • I have been experimenting with something where you have standardized elements because the Fetch API doesn’t throw on 4XX/5XX, so having one if check, rather than two, makes sense.

          At this point, it’s an experiment.

          • TehPers
            link
            fedilink
            1
            edit-2
            11 months ago

            Status codes for batch operations is always a mess. Do you return a 400 because one request made no sense even if the rest succeeded, or return a 200? 207 exists but it’s not really directly part of the HTTP spec and only seems to support XML response bodies.

            Edit: @[email protected] if the RFC proposed a solution to responses for batch operations where some responses may contain errors, then that would be interesting. The RFC, from what I understand, proposes a format for error responses, but does not seem to support mixed error/success responses.

  • TehPers
    link
    fedilink
    English
    1
    edit-2
    11 months ago

    Link seems to be broken for me, but adding your choice of {.html,.pdf,.txt,.xml} to the end of the URL seems to fix it.

    This also works.