search

mmontone / cl-rest-server

Serve REST APIs from Common Lisp
http://mmontone.github.io/cl-rest-server/cl-rest-server/
MIT License
66 stars 9 forks source link

Split rest-server and rest-client into separate systems #10

Open naryl opened 3 years ago

naryl commented 3 years ago

It's a big missed opportunity. We should be able to use the same define-api definition for the client and the server with the server having all the implement-resource-operation and the client using with-api-backend. I'll have a go at this myself.

IMO rest-client system can get all the common code with rest-server depending on it.

mmontone commented 3 years ago

Ok! Give it a try. Not sure how hard that would be.

Note that client side functions are generated. You know that, didn't you? Client functions get expanded for DEFINE-API. Take a look at CLIENT-STUB definition and DEFINE-API-RESOURCE macro. You can control the package of the generated client functions via :CLIENT-PACKAGE and :EXPORT-CLIENT-FUNCTIONS options.

But yeah, those generated client functions are functions for consuming the REST-SERVER service, not some external service (that implements OpenAPI, for instance.)

naryl commented 3 years ago

I changed my mind. There should probably be a rest-common too since looks like only client-stub uses drakma. So, it's not needed on the server.

Also rest-client would be a library, not a framework, so it should probably avoid logging completely and use conditions instead. Is it ok?

mmontone commented 3 years ago

Yes! Whatever you feel is better. I'm not exactly sure what your result would be.

I'm not exactly happy with client function generation when expanding DEFINE-API. Perhaps there's a better way, like using DEFINE-API in one place, and then use another macro in a different place that consumes the defined api and generates a client library.

But I'm not sure; that's how things are right now.

Symbolics commented 3 years ago

I've been looking at the two projects I mentioned in #11 and it seems aws-sdk, whilst without documentation, code comments nor a very clear style, does generate code with a lispy syntax. It seems to handle the parameter conversions, and if it's robust enough to do the entire AWS SDK, should be able to do most any other OpenAPI defined API (though AWS is a non-standard derivative)

How might this issue be moved forward? @naryl mentioned a rest-common module which may be something that aws-sdk could be re-targeted to. I'm not exactly clear what the overall architecture might be here. Though. Are we thinking something along the lines of:

define-api (...) -> OpenAPI-spec

and then using the OpenAPI specification generated to produce client and server side stubs? If so then aws-sdk could be modified to output the client-stub intermediate representation, like so: OpenAPI -> aws-sdk -> client-stubs. Although in that case, since aws-sdk makes HTTP calls itself, at least for AWS, would client-stubs still be required?.