search

ahx / openapi_first

openapi_first is a Ruby gem for request / response validation and contract-testing against an OpenAPI API description. It makes APIFirst easy and reliable.
MIT License
115 stars 15 forks source link

Expose operation on the runtime_request. #216

Closed MrBananaLord closed 8 months ago

MrBananaLord commented 8 months ago

I'd like to be able to programmatically access the OAS definition details. Exposing the operation would make it possible by doing: request(env).operation[key]

What do you think about that? :)

ahx commented 8 months ago

Hi! After reading about OpenAPI 4 (which thinks more in "requests" than "operation"), I have made some Openapi 3 specific jargon less visible from the API in 1.0 to get a good chance of being backwards compatible when "Moonwalk" is coming. However, at this point this seems pretty premature. So I am open for the idea if you need it, but if possible I would like to use a more abstract API instead.

What field do you want to access specifically? Did you see RuntimeRequest#path_definition?

MrBananaLord commented 8 months ago

We have a custom property x-foo. So maybe we could make all custom properties exposed instead of the whole operation 🤔 https://swagger.io/docs/specification/openapi-extensions/

ahx commented 8 months ago

We have a custom property x-foo. So maybe we could make all custom properties exposed instead of the whole operation 🤔 https://swagger.io/docs/specification/openapi-extensions/

That sounds like a pretty common use case. I have two ideas about this:

  1. expose .operation as you did here
  2. call it something "more abstract" like .definition or the like.

…I think i prefer 1., because it is less confusing if you already know OpenAPI, which you probably do if you are using this gem :)

MrBananaLord commented 8 months ago

I'd go with the .operation :D