Follow OpenAPI model for next version

[mmontone]

REST-SERVER model is based on resource and resource operations.

Latest OpenAPI model differs from that, it is based just on HTTP methods and paths.

If OpenAPI stabilizes, it could make sense to adapt REST-SERVER model to that. That would improve OpenAPI integration, and maybe more.

[Symbolics]

Just putting a few projects that use or implement REST into this issue for consideration.

https://github.com/incjung/cl-swagger-codegen
https://github.com/fiddlerwoaroof/aws-sdk-lisp

I think there's value in having a consolidated REST library to work with the likes of Azure, AWS and GCP, plus all the other applications that now seem to use REST instead of RPC.

Perhaps an API something like this:

rest:get <#URI for fragment> :from <#my-endpoint>
rest:put <#my-CLOS-object> :to <#another endpoint>

as a higher level REST API that deals with the endpoint and JSON stuff and something like dexador for the HTTP protocol as a lower layer (Dexador uses winhttp for Windows, so is pretty good from a cross-platform perspective, and the API verbs make sense when working with the HTTP protocol.)

Was also thinking through the idea of using OpenAPI as either an intermediary or primary source for the API specification and can see a few advantages in allowing third parties to get at the functionality. If we have a server that obeys the spec, then other language bindings could be generated for, say, Python and expand the range of users.

Given a choice though, I'd rather have a good version of a client side API generator, as there are hundreds of APIs I'd like to consume right now that have OpenAPI (Swagger) specifications that are not in easy reach for Lisp users. The server could come later.

[mmontone]

Given a choice though, I'd rather have a good version of a client side API generator, as there are hundreds of APIs I'd like to consume right now that have OpenAPI (Swagger) specifications that are not in easy reach for Lisp users. The server could come later.

Just for reference, there's this, but I haven't tried it: https://github.com/kat-co/openapi2cl

[Symbolics]

Thanks. I saw that, but didn't include it because it doesn't seem much better than cl-swagger, but more importantly it's GPL, which means it can't be used in most commercial projects.