Open stkrwork opened 6 years ago
I'm interested in restbed generator, what I don't like with current implementation is, that it requires to modify generated code, there's no way to inject your own handlers, as restbed does not allow to set REST method handler few times. So if you set handler two times (you'd expect to overwrite old one) only first will be called (and that one is taken by generated code). Basically at this moment this generated code is either useless (because we need to call restbed manually) or cant be regenerated.
My idea is to add
std::function<int(...)> callback_;
to generated classes, this way it would call the callback and expect status_code reply from it.
So if you regenerate auto code your code won't get overwritten.
I've got this working, is there any interest in PR?
@muttleyxd Please open a PR, so we can take a look
Hi @stkrwork , Hi @muttleyxd ,
sorry to go over this "old" issue... I just tried using the restbed server-side generator with both the OpenAPI generator CLI v4.3.1 and v5.0.0-beta2 and I stumped over the same problem described by @muttleyxd : the automatically-generated restbed::Service-derived class is publishing in its constructor the restbed::Resource... That means there's no chance to set the GET handler or whatever other handler exists on the restbed::Resource...
how am I supposed to use the generated C++ code? Do you have any hint? Or any working example?
@muttleyxd : did you manage to open a PR ? I could help on that perhaps...
Thanks
Well, I did open a PR, where you can set the callback through the method
but now I see it was a bad idea. A good refactor would be to do it like in Pistache generator (PetApi would be class with virtual methods and user would have to override these in their handler code).
Well, I did open a PR, where you can set the callback through the method
but now I see it was a bad idea. A good refactor would be to do it like in Pistache generator (PetApi would be class with virtual methods and user would have to override these in their handler code).
yeah I totally agree - virtual methods look like a better way to make the code extensible rather than callbacks attached to the restbed callbacks... that double layer of callbacks also makes debugging less clear
For an internal project, I'm improving the generation of restbed code. The goal is that the generated code doesn't need to be edited. It works with inheritance. I'm considering to contribute my changes back to the community. But it's quite a big change and is not backward compatible.
I'm currently on 5.1.0. But as the generated code is not backwards compatible, I would probably put my changes in a later release.
Hi guys. Any status on this? Restbed looks like the best platform for us, and I've generated code for it from our OAS 3.1 definition; but I don't really understand how to use it. There are no documents that I can find, and no examples. Aggravating.
Sorry for the missing documentation.
Here some hints how to implement an API. This is code for a newer version of the restbed generator. With your version there are probably more shared_ptr
s involved and the names of the generated classes are more verbose. But I think this example should help to get started.
#include "api/PetApi.h"
using namespace org::openapitools::server::api;
using namespace org::openapitools::server::api::PetApiResources;
class MyPetApiPetPetIdResource : public PetPetIdResource {
public:
int handler_DELETE(int64_t &petId,
std::string &api_key) override {
return 200;
}
std::pair<int, Pet>
handler_GET(int64_t &petId) override {
auto pet = Pet();
return std::make_pair(200, pet);
}
};
int main() {
const auto service = std::make_shared<restbed::Service>();
auto petApi = PetApi(service);
petApi.setResource(std::make_shared<MyPetApiPetPetIdResource>());
const auto settings = std::make_shared<restbed::Settings>();
settings->set_port(1235);
service->start(settings);
}
Thanks for the code, but this doesn't help me generate it. I'm looking at modifying the Restbed template or making my own, but the documentation that discusses custom templates and generators does not seem to have orderly procedures in it.
Is there any tutorial that shows the complete flow from API-spec document (YAML or JSON) to output code? I assume the generator must parse the OAS document into a common data model, and then pipe that model through the Mustache templates to generate the files. But I can't find any reference to what that data model is or how Mustache works.
Description
Restbed Generator needs to be reviewed and refactored.
Suggest a fix/enhancement
review current code, and refactor if necessary