Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Openapi yaml imports issues #213

Open
awb99 opened this issue Dec 14, 2024 · 2 comments
Open

Openapi yaml imports issues #213

awb99 opened this issue Dec 14, 2024 · 2 comments

Comments

@awb99
Copy link

awb99 commented Dec 14, 2024

There is this github repo that has hundreds of open api specs in yaml files:
https://github.com/APIs-guru/openapi-directory

I used the yaml to edn converter from martian to get edn files.

But turns out none of that api yaml files work.

To me it really sounds like the clean way to use such yaml files.
Any ideas as to which features in martian are missing so that such an
Approachbis feasible?

Thanks!

@oliyh
Copy link
Owner

oliyh commented Dec 14, 2024

Hi,

What errors do you get? I'm pretty sure someone is using the k8s API via martian, which is massive.

Cheers

@awb99
Copy link
Author

awb99 commented Dec 14, 2024

This is the edn file from converting yaml to edn if Google calendar api:

https://github.com/pink-gorilla/rest/blob/main/demo/resources/calendar.edn

I believe the refs/components are an issue.

The paths are keywords that contain / character; I believe this nto
Valid edn.

I could not find a documentacion how the intermediary edn
File should look like. To me it had a different structure than a
Manually written file.

BTW: I have written a library that allows the user to authorize oauth2
permissions in the browser and that handles access token refresh.

https://github.com/pink-gorilla/oauth2
And in https://github.com/pink-gorilla/rest I use martian with some apis
That are currently manually specified.

If martian could use apis from this openapi collection that
Would mean añl.services form google amazon and some other huge
Apis are immediately useable.

I believe this approach is way better than the api generator that
Many apis have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants