Re: [httpapi] rfc7807 errata or just "more"

[Sanjay Dalal <[e-mail]>]

Hi Darrel,

>Just pointing to the instances of the failures without describing what
kind of failures those are would not be a great experience.

I agree. However, if we have a schema that accommodates pointers to
failure(s) and more details about the errors as part of RFC it would help
many API developers. Such a schema could be defined in a very generic
fashion like what we have attempted to do in the error catalog service API
at
https://github.com/sdatspun2/error-catalog-service/blob/master/ErrorResponseInErrorCatalog.md.
These schemas are derived from rfc7807 and from JSON Schema spec, section
10 respectively.

>That additional information about what kind of failures each of those
instances experienced is going to need to be in extensions and the client
will need to understand the semantics of the type...I accept there will be
some scenarios where there are multiple instances of problems associated
with a single resource that are homogeneous, but there are going to be just
as many that are heterogenous. I don't really see the issue with using the
type to define the necessary extensions.

If we can provide a solution for the homogenous use case (I believe that is
80% in 80-20) and suggest to use extension for the heterogenous use case
that would go a long way, imo. In fact, it would increase adoption of
rfc7807 significantly. I did not use rfc7807 while designing PayPal's
proprietary
schema
<https://github.com/paypal/api-standards/blob/master/api-style-guide.md#error-handling>
for the error response. I am sure we were not alone.

Thanks.
sanjay


On Sat, Jan 16, 2021 at 1:41 PM Darrel Miller <[e-mail]>
wrote:

> Hi Sanjay,
>
> *From:* httpapi <[e-mail]> on behalf of Sanjay Dalal
>
> As you know, having multiple schema validation related errors in payload
> of HTTP requests is a very common scenario for the HTTP APIs.
>
> I'm not sure an instances array is going to solve the issue here.  In your
> example, at the resource level, multiple issues have been detected as
> schema validation problems and you will need some explicit type to identify
> schema validation problems..  As you say there may be many validation
> constraints that were violated within the response payload.  However, it is
> likely that they are more than one type of validation failure.  Just
> pointing to the instances of the failures without describing what kind of
> failures those are would not be a great experience.  That additional
> information about what kind of failures each of those instances experienced
> is going to need to be in extensions and the client will need to understand
> the semantics of the type.
>
> I accept there will be some scenarios where there are multiple instances
> of problems associated to a single resource that are homogeneous, but there
> are going to be just as many that are heterogenous.  I don't really see the
> issue with using the type to define the necessary extensions.
>
> Darrel
>
>