[FEATURE] Support multiple request methods

[w2534073922]

The callback interface may include both GET and POST requests. Currently, this plugin only supports the POST method. It is hoped that it can be compatible with multiple request methods. I have reviewed the plugin development documentation of Dify. Currently, only one request method can be defined in the YML file. I hope this restriction can be lifted.

[perzeuss]

Hello @w2534073922 ,
For what purpose do you want to implement a GET request? What would be your requirement for such a request? What should a response look like?

If there are useful use cases, I'm happy to implement it.

Are you aware that dify apps can only run in the foreground? For example, it's not possible to start a workflow with a GET request in the background without waiting for it to finish. Most integrations time out on GET requests that take a long time.

[w2534073922]

I hope to forward the messages received by the company's robots to the intelligent agent. However, the robots have requirements for the callback interface, which must support both GET and POST methods, as it will receive both GET and POST requests.

[w2534073922]

Additionally, I discovered a problematic situation. The company's robots require that the callback interface must respond within 3 seconds after receiving a message. If I send the robot's message to the agent, it means it will take a long time to respond. Is there a way to solve this issue? Can asynchronous and multi-threading be used in the plugins of Dify? It seems that I will have to code this task by myself, but I'm not sure if the working mechanism of the dify plugin allows for this.

[perzeuss]

Additionally, I discovered a problematic situation. The company's robots require that the callback interface must respond within 3 seconds after receiving a message. If I send the robot's message to the agent, it means it will take a long time to respond. Is there a way to solve this issue? Can asynchronous and multi-threading be used in the plugins of Dify? It seems that I will have to code this task by myself, but I'm not sure if the working mechanism of the dify plugin allows for this.

This is a known limitation, which is why I asked. Endpoint plugins run serverless in AWS Lambda. You need a server that continues running beyond the runtime of the request.
I have developed my own extension that makes it possible to run background jobs. This way an incoming webhook can start a job and the job then runs in the background. However, I've paused my work on it, because it's very complex to build a modular and flexible solution. In any case, you'd have to run an additional server/container, or implement this feature natively with the Dify worker, which could actually run jobs in the background but is currently not designed do scale with these kind of jobs.

[w2534073922]

Thanks for your explanation. I've found a temporary solution.

I execute the reverse invocation of the app in a separate thread. After starting this thread, the main thread needs to pause for a short time, and this seems to work:

thread = threading.Thread(target=_wrapper)
thread.daemon = False
thread.start()
time.sleep(0.8)

It's possible that some context objects are destroyed after the interface responds (after the return statement), and the "reverse invocation" relies on these context objects. By using the code above, the reverse invocation can start executing first, allowing us to use the context object before it becomes invalid.

This approach is pretty hacky, though. I haven't received an official solution from Dify yet.