Questions, Ideas, and Suggestions

[dcj]

Suggestion:
Enable "Discussions" on this repo so non-issues can be addressed there, instead of having to file an issue for something that isn't, like this!

Questions and Ideas/Thoughts:

IMO one motivation for OpenAPI and Martian is meta-programming.
The bootstrapped Martian record is super useful, and I've been writing code that walks all the :handlers and does stuff. But there are times I would like to just have access to "the entire unprocessed OpenAPI spec after it was EDN-ized". So the idea is add that to the Martian record. ATM I can go get the :openapi-definition for each handler, and that is OK, but one thing I would like to do is generate a Malli schema for each {:$ref "#/components/schemas/FOO"} Currently I can go walk all the handlers and get a (redundant) collection of those schemas, but seems like it might be more straightfoward to walk the unprocessed OpenAPI spec rather than the dereferenced/resolved schemas within each handler.

Scenario:
Some service provides an OpenAPI spec
The service API contains three classes of endpoints/routes:

• Endpoints that do not require auth
• Endpoints that require an auth token
• An endpoint/request used to obtain an auth token

My (generated by/with Martian) client would attempt to distinguish between those three endpoint types, and add interceptors that handle the three auth variants above.
Endpoints not requiring auth are easy :-)
The endpoint used to obtain an auth token presumably needs some sort of secret and userid, which I would like to stick into the Martian record. I can just assoc them in, or perhaps add them to the record's metadata.
Then the handler + interceptor for this endpoint would just go get these credential out of the Martian record....
When the get-auth-token handler succeeds, I'd like to stick that auth token into the same Martian record, again, either assoc it in, or add to metadata.
The interceptor added to each handler requiring auth-token would again obtain the token from the Martian record.
As we all know, auth tokens can/do expire.
Ideally, when a handler-requiring-token fails (due to auth), it would be cool if some interceptor caught this, invoke the get-auth-token handler, and retry the original handler-requiring-token.
This implies that the thing storing the acquired auth-token is mutable. So maybe stick it in an atom within the Martian record/metadata?

I welcome thoughts, comments, critiques on this, including (constructive) "you are thinking about this all wrong and here is why" admonitions.