HTTP OPTIONS response with metadata

[jayvdb]

http://zacstewart.com/2012/04/14/http-options-method.html and several others have lamented that HTTP OPTIONS is rarely used effectively. It is mostly used for CORS preflight requests, and the Rust frameworks usually have a plugin which does support this.

Django's DRF does provide a default JSON response body filled with lots of metadata which can be seen at https://www.django-rest-framework.org/api-guide/metadata/ , and there are more advanced DRF packages which provide different output such as https://github.com/drf-forms/drf-schema-adapter and https://github.com/django-json-api/django-rest-framework-json-api . Projects using this DRF setting somehow can be found at https://github.com/search?q=DEFAULT_METADATA_CLASS&type=code

There are clients which automatically use those responses to have an up-to-date knowledge of the schema for the specific endpoint they are about to access, i.e. not having to either use a pre-generated client, or regularly load the entire schema from a custom endpoint such as /schema to know the server's endpoints.

I've found similar in other backend frameworks, but I cant recall them at the moment.

I think it would be wonderful if utoipa provided some glue to make this possible (even easy..) with common Rust web frameworks.

[juhaku]

@jayvdb This would be a good addition to the library and happy to have something like this included. However since there is no common standard (at least to my knowledge) it should not be enforced to everyone. Maybe there could be another crate that provides this kind of additional functionality to the utoipa. Then these users can add it as a separate dependency to get the functionality.

There even could be multiple different crates e.g. one providing syntax similar to Django and one for something else. Probably something similar to Github could be done if it has support for such metadata at least for starters.

Yet this is not something I would be focusing on, at least at the moment with the development of this library. But if there are willing contributors to implement such functionality I am more than happy to include such contributions to the ecosystem. :slightly_smiling_face:

At least if the existing ToSchema::schema() function can be used to generate a schema for the metadata then implementing support for this should be doable with relatively small effort. But if the schema needs to be done from scratch then there is some engineering effort to be done to get feature parity with the current schema() function.

There even could be some API or way to programmatically via types to create or at least help to build such metadata responses. But that is just a matter of implementation details.