Closed mbuhot closed 1 year ago
This may be an oversight in the json hyperschema as well, but we actually have some fields that don't come back by default, but may be populated with the fields
option, specifically calculations and arguments. I haven't looked at how we do that in the code, but we'll just want to make sure this reflects whatever that behavior is.
Hey @mbuhot I'd be down to get this stuff merged and just let people play around with it, if you are :) It won't be in the critical path for anyone, so we can fix issues as they arrive. If you're cool with that go ahead and take it out of draft and we can roll forward on it 🙇🏻
Hi @zachdaniel, Looks like I've got some linting and type specs to fix up, and some unfinished tests. I'll try to get the build passing over the next day or two so it can be merged and give folks a chance to try it out and see how it suits.
Sounds great!
Sounds great!
it seems works fine but it a little bit alot of files to write so i am thinking about make modules uses Ash.Api generate it instead of write modules for open_api specs for every api.
open_api do ver "1.1" title "dummy" tags? true
end
It should only need to be on the api and not the resource right? How many API modules do you have?
It should only need to be on the api and not the resource right? How many API modules do you have?
i am really want to work with ash but know i have just a taste with ash but i think you could have more than one.
You're right, you'd likely have more than one. We may actually need to take that into account here and have the schema generated for multiple APIs instead of a single one. At the moment ash_json_api generates the json schema and these specs for one api at a time. Either way, you likely would not have very many APIs in total. But it doesn't hurt to do what you said.
You're right, you'd likely have more than one. We may actually need to take that into account here and have the schema generated for multiple APIs instead of a single one. At the moment ash_json_api generates the json schema and these specs for one api at a time. Either way, you likely would not have very many APIs in total. But it doesn't hurt to do what you said.
i will try my best spark seems a very fluent to play with it, and i will try to implement this.
Superseded by https://github.com/ash-project/ash_json_api/pull/72
This PR adds functions to allow an application using AshJsonApi to expose an OpenAPI spec via the OpenApiSpex library and some new helper functions.
This is different to the approach I was originally using in #63, the trade-off being that now the user has more control over the complete OpenApi document, at the cost of a little boilerplate.
Contributor checklist