drf-forms / drf-schema-adapter

Making using Django with frontend libraries and frameworks DRYer
http://drf-schema-adapter.readthedocs.io/en/latest/
MIT License
157 stars 40 forks source link

AutoMetadata discards DRF format #59

Closed jayvdb closed 1 year ago

jayvdb commented 4 years ago

The AutoMetadata inherits from SimpleMetadata, but has a wildly incompatible output.

The output of the base class is

{"name":"foo","description":"","renders":["application/json","text/html"],"parses":["application/json","application/x-www-form-urlencoded","multipart/form-data"],"actions":{"GET":{...}}}

Most of that data is missing from the drf-schema-adapter AutoMetadata, and the name is moved to be under ui.label. Is the AutoMetadata response loosely following some spec; if so, which one? I suspect that the DRF SimpleMetadata has no spec, but they are implicitly the standard setter for Django REST, and there are lots of frontend apps which expect/use that format. It is a defacto standard, for good or ill.

The OPTIONS response is fairly flexible according to the spec, but drf-schema-adapter should provide the response some content-type like application/json+foobar to give a clue what it is.

I see that AutoMetadataMixin.determine_metadata does invoke the DRF SimpleMetadata.determine_metadata, and it gives that to the adapter, defaulting to adapters.BaseAdapter, which then discards all of the metadata provided by DRF SimpleMetadata.determine_metadata.

IMO the default drf-schema-adapter adapter should enrich the DRF format, not discard the elements it provides, as that makes the default adapter incompatible with DRF.

If not the default adapter, there should at least be one adapter which does extend the DRF format with extra fields, if only as a demo of how this library can be used to extend existing DRF based clients.

nanuxbe commented 1 year ago

There is no specification for AutoMetadata, the specification is determined by the adapter used and are explained here with relevant links to the different scpecifications.

I am not sure there is a case for using both DRF's specification and JsonSchema (the specification of the base adapter) but you might have one. One way to accomodate that would be to create and use a custom adapter with a different render method