You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From looking at response/error_*.yaml, it seems like pretty much all the errors have the fields of response/error.yaml, as well as an additional item field, which is left opaque to be extended in different endpoints. Could we not instead have a response/error_with_item.yaml which has the response/error.yaml fields + an item field, and reuse that for all the errors in different endpoints, so that there are not many different error types which are actually practically identical? It seems to me that this would be an easier way to organise things
The text was updated successfully, but these errors were encountered:
is misleading. It specifies a oneOf describing two alternatives which the error format might take, but the two errors are structurally the same, so it doesn't really matter which one we specify. Not only does it not matter which one is specified, but it is also impossible to distinguish between them. Consider
From looking at
response/error_*.yaml
, it seems like pretty much all the errors have the fields ofresponse/error.yaml
, as well as an additionalitem
field, which is left opaque to be extended in different endpoints. Could we not instead have aresponse/error_with_item.yaml
which has theresponse/error.yaml
fields + anitem
field, and reuse that for all the errors in different endpoints, so that there are not many different error types which are actually practically identical? It seems to me that this would be an easier way to organise thingsThe text was updated successfully, but these errors were encountered: