Hi.
As of Wappler 5.3.1, when creating a an API server action, it can be consumed using either GET or POST HTTP methods.
But there is no way to identify or restrict if the API is a GET or POST type.
This feature has been briefly discussed years ago, from what I recollect. So creating this post since I could not find any.
The idea is that instead of having EXECUTE node, there could be different NODEs, 1 each for HTTP method - GET, POST, PUT, PATCH, DELETE etc.
Above such nodes would be a GLOBAL node, which could include common initial steps like authentication etc. It could also be just called EXECUTE as to not confuse with the Globals section.
For existing SAs, I see two ways to update:
Keep current steps in execute/global, so no changes needed.
Show a prompt to select which HTTP method to update to. Then, any common steps could be manually moved to execute/global node.
Two more points to consider:
HTML Form element does not support other HTTP methods except GET and POST. So this request would cater more to APIs being created for consumption outside Wappler. But it will still help merge separate SAs for getting data to view (via SC, GET) and editing data in DB (via Form, POST).
This would probably also ignite the discussion around copying steps across SAs to merge different SAs used specifically for view, edit, delete etc. Maybe something that could be considered as well after this is implemented.
I don’t have the designing skills of @nickneustroev, so just in writing.
Hope this makes sense to be implemented as the next evolution of API/SAs in Wappler.
I specifically did not suggest that because its not part of the HTML Form standard.
It would make more sense to merge the API Action and Server Connect components rather, to have those HTTP methods available on client side.
Actually this is already possible. In the Routing Manager you can add server connect routes manually and then choose the method they should respond to:
As I understand that’s a common case, when the same endpoint works differently for different methods. So I agree that this feature would be useful.
In terms of implementation I feel like it would be more comfortable, if different methods would be separated and would be presented as different nodes in the api structure.
At the first glance I don’t see much need in combining all method’s workflows in one, as you suggest. But maybe you can provide more examples when it would be helpful.
Here are some quick design ideas, how it could look.
Sorry George, but this isn’t remotely what I am asking for.
I tried this very long ago, and it didn’t even work… haven’t tried recently. Although, all this does is restrict the request to a particular method - but does not help in the SA itself, which is the main goal of my FR.
And it would be a nightmare to manage this in the routing panel.
Thank you for finding the time to build the mockup.
I get your point about not wanting to have different methods in single file - but having them separate, with multiple entries in the list is pretty much same as what we have right now. Only additional benefit being the tags.
I really like the third design, but it is going to very difficult to follow if each set is not kept in a separate folder.
Having multiple sections in the same file means no change in existing file system, and since the methods would be collapsible - similar to the INPUT node - it should not cause much problem. Not very elegant I agree, but could work.
