Thank a lot for your proposal! To be honest I'm skeptical about it. But let me share some thoughts how it could be implemented using an extension in v1.1 anyways. #11
Description
Thank a lot for your proposal! To be honest I'm skeptical about it. But let me share some thoughts how it could be implemented using an extension in v1.1 anyways.
An extension can define additional members of the top-level document:
An extension MAY define new members within the document structure defined by this specification.
The name of a member defined by an extension must be prefixes with a namespace:
The name of every new member introduced by an extension MUST be prefixed with the extension’s namespace followed by a colon (:).
That means it could not just be warnings, but it could be warnings:warnings if that extension registers warnings as its namespace.
Maybe it would be good to extend scope a little bit and support other debug information like info as well. In that case a broader namespace like debug may be more appropriate.
All of these are valuable for the developer to know, but JSON:API doesn't give us anywhere official to put them.
In most cases APIs are meant to be consumed by computer programs. Not sure if API response is the best way to communicate with the developers who are developing clients consuming them.
In my experience developers inspect the API response only if changing how client consumes that API or if debuging an issue, which might be related to an API response. So I wouldn't expect that such a warning is noticed by a developer at all.
Additionally it comes with a noticable trade-off of increased payload size. Avoiding to send data, which is not needed, over the wire (over-fetching), is one of the most hyped features of GraphQL.
_Publicado originalmente por @jelhan en json-api/json-api#1592 (comment)