Exactly like the server action form that wapppler has.
To summarise.
Ability to submit any available wappler data ServerConnect Data/Appconnect Data in a json body and URL string to the 3rd party API using post/put.
The response will be a status (200,404 etc) and off course any json data the server responds with.
The Json returned may can contain more details such as server Side data from the 3rd party DB and may be an array or nested arrays etc.
This json returned should be available inside the wappler json data source or alternative , so it can be visually rendered or further processed on serverconnect.
it would be great to pass binary data such as file upload, but the ability to bind
any wappler data to a post body, is paramount. The data can come from the form on a page, from a query developed in server connect, cookie, session storage etc.
I think there are 2 types of 3rd party APIs. First you have public APIs that can be accessed without any credentials, you could access these with App Connect directly using some AJAX requests. On the other hand you have APIs which require some authentication using an API key, OAUTH or something else. These mostly must be implemented server-side, so should be implemented in Server Connect.
The client-side implementation is just as Server Connect, but it should be extended a bit with support for custom headers, put and delete.
With the server-side an action in Server Connect would do the API call and return the data, on the client-side you just call the server action like you do now.
The only problem I see is that for us the APIs are unknown, we donāt know what the API expects as parameters and what they return. Because we donāt know what it returns we donāt have the meta data required to fill the data pickers in Wappler. The question is how to solve this, most APIs have always the same properties in the output, so we could do a sample call when the action is created and use the result as meta data. But a lot of modern APIs have optional properties, it does not have to return all properties on each call, also the output could change depending on the input. And then we also have error handling, most will return some status code, but some APIs return the error in the result.
I was thinking about this, and maybe the following could work:
Let the community select and vote for the most desirable APIs/services to connect to and implement support for those.
Then, with time, add support for more APIs (just like Zapier, Piesync, Integromat and others do).
And finally, for all the other APIs, add a generic connector, so at least it will be possible to connect with services that don't demand more specific setup.
As i see it
best solution is to make the developer type the parameters names and types then wappler save and use that as the meta data so the developer can edit the meta when needed.
I recreated the Unsplash video like the tutorial on DMXZone and it worked perfectly, so about to try some real world stuff. If it works, which I am sure it will then I will only start begging for the server side of this on Tuesday so I do not look too greedy.