You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the use-open-api-generator branch, you will find the a complete auto-generated API client for the endpoints currently available in the swagger.json on catalog.api.wfp.org using https://openapi-generator.tech/docs/installation
In the README there is a code example that I have tested and works (you just need to place your token in the code). The auto-generated docs also show all the endpoints that have been immediately available. As you are familiar with the API, it should be easy to see the small changes one would need to make to point to different endpoints.
The advantage of this approach is that the code for all the endpoints is generated in seconds, and this could be done in all these languages. The code can be regenerated easily anytime endpoints change. The way one makes a call is a little clunky but not the end of the world.
If we were to go down this route, we would need to integrate this code with the functionality to refresh the token automatically. Probably not very difficult, but still something to spend some time on.
So my question here is: does this auto-generated client seem like a good way to go? If yes, the next step would be to look into the token refresh.
@paololucchino@martinig94
I think the big advantage of what we have now, which Giulia implemented, is the compatibility with the way our API Gateway delivers access externally. This happens not through Oauth2 account token, but through application key:secret pairs.
If we're able to embed this in the auto-generated library and to include the token refreshing we likely take the best of the two worlds: having something compatible and always up-to-date.
In terms of usability from the final users, I would have to do some testing...
Thanks @ValerioGiuffrida . Indeed, that is the work that would be needed (ie add functionality to the autogenerated code to handle the token refresh). I think it is doable by creating a simple wrapper class over the autogenerated client.
But before I look into it, I just wanted to check that the usability of the autogenerated client was ok for the team. Please have a look and I'll wait for a green light from you. =)
Hi @ValerioGiuffrida ,
In the
use-open-api-generator
branch, you will find the a complete auto-generated API client for the endpoints currently available in the swagger.json on catalog.api.wfp.org using https://openapi-generator.tech/docs/installationIn the README there is a code example that I have tested and works (you just need to place your token in the code). The auto-generated docs also show all the endpoints that have been immediately available. As you are familiar with the API, it should be easy to see the small changes one would need to make to point to different endpoints.
The advantage of this approach is that the code for all the endpoints is generated in seconds, and this could be done in all these languages. The code can be regenerated easily anytime endpoints change. The way one makes a call is a little clunky but not the end of the world.
If we were to go down this route, we would need to integrate this code with the functionality to refresh the token automatically. Probably not very difficult, but still something to spend some time on.
So my question here is: does this auto-generated client seem like a good way to go? If yes, the next step would be to look into the token refresh.
cc @martinig94 @trenouard
The text was updated successfully, but these errors were encountered: