OpenAPI 3

[maksbotan]

Based on GetShopTV/swagger2#219

Tests pass, did not check on a real code yet.

[maksbotan]

This one is ready as well.

I have one doubt, though. OpenAPI 3 has components field, where one can put request bodies, params, headers, responses and so on and reuse them across operations.

Would it make sense to try to extract common requests, params etc in servant-swagger? For example, if RequestBody combinator is applied to sub-api with multiple Verb's, we could store the spec for it in components.

Apart from this, servant-swagger from this branch is in a usable state: I've tried porting our project and it works, including sum-types.

Event servant-swagger-ui works without modification.

[sir4ur0n]

For what it's worth, I have tried on our (private, sorry) project, and it works really well!

We used the UntaggedValue encoding and it works like a charm ❤️

Note, I had to manually copy/paste the generated schema in https://editor.swagger.io/ as the servant-swagger-ui project is not yet adapted (dependency boundary, but there may be other adaptations required?).

Thank you for your work on these PRs, this is awesome!

[roosemberth]

Would it make sense to try to extract common requests, params etc in servant-swagger? For example, if RequestBody combinator is applied to sub-api with multiple Verb's, we could store the spec for it in components.

I think this is a good idea. Even better: Add another parameter to extract all requests, params, etc... to top-level component definitions.

[maksbotan]

This has a new home now as well: https://github.com/biocad/servant-openapi3 🎉

[sir4ur0n]

Hi, so what's the status of this PR? Will this development land in servant-swagger or remain in a dedicated servant-openapi3 package?

If new package:

• Shouldn't servant-openapi3 belong in the haskell-servant Github group?
• Shouldn't servant-swagger readme/documentation state that it's a deprecated package, and users should migrate to servant-openapi3? I don't see the point of maintaining both packages (except for a few months for retro-compatibility reasons)

If it lands in this package:

• Are there remaining steps to merge it?

Thank you!

[maksbotan]

Hi! Thanks for your interest!

I'm definitely going to release openapi3 and servant-openapi3 to Hackage. I was planning to do it once I figure out how to update servant-swagger-ui, so expect something on the weekend or on the next week.

As far as I understand, @fizruk proposed to go the "new package" way. Once I make Hackage releases, I will make PRs mentioning the new packages in the old ones' READMEs.

Personally, I suppose that the two packages will coexist for a while, since switching from Swagger to OpenAPI3 is not a trivial process for users, as this will require some work with frontends, infrastructure, etc.

Re haskell-servant: that would be nice! I suppose @fisx or @phadej can say something on that matter. I would be happy to move the repo.

[fisx]

I haven't been keeping up with what's going on here, but it sounds exciting.

Yes, I would definitely like to host all relevant packages under haskell-servant!

[normenmueller]

@maksbotan https://github.com/biocad/servant-openapi3 looks promising. Nice! Are there any news on

I'm definitely going to release openapi3 and servant-openapi3

I'd like to try it out.

[phadej]

except for a few months

👎

[akhesaCaro]

Hi,
Servant-swagger will be moved into the main Servant repo (see : haskell-servant/servant#1475)
If this issue is still relevant, would it be possible for you to rebase on that repo (when it will be merged)? : https://github.com/haskell-servant/servant/

Thanks in advance!

[maksbotan]

Hi @akhesaCaro!

This PR (and, in fact, the entire swagger stuff) is superseded by https://github.com/biocad/servant-openapi3 (https://hackage.haskell.org/servant-openapi3).

I believe I've mentioned that in haskell-servant/servant#1475.

[maksbotan]

Closing this outdated PR.