How to design an asynchronous Web service-Interface Section

The requirements are relatively simple and provide an asynchronous Web service for the consumer to invoke. For example, an application needs to add a lomo effect to a picture in bulk. Due to the Lomo effect this operation consumes CPU resources, so we need to put the Lomo effect of the program logic on a separate server to run, so as not to affect the application itself on the server performance.

This first talk about the interface part of the service, focusing on clearing the application and service between the call relationship, if there is time, then write an essay on the Service internal task dispatch resource scheduling.

Based on this requirement, we can quickly design a set of processes:

Application creates a task by providing information related to the service's AddTask interface post task, and the service returns the task ID of the task, which is taskid to application, So that application can then use this taskid to query the status of this task through the GetStatus interface.

Question one:

Application as a standalone application, he certainly needs to have his own task management logic. That is, application must write a corresponding data for the task to its own DB before issuing a request to the service to create the task, so that the status and data of each task can be tracked later. So how do you application this response taskid and the data that I wrote to the DB when I receive response?

If it is the interface design above, it should not be able to achieve this requirement. So we need to add a parameter customid to the AddTask interface to mark the uniqueness of the task. Such as:

Question two:

Based on the design above, application will constantly invoke the service's GetStatus interface to get the latest state of the task, such as whether the task is waiting, running, or completed after the task is created. However, this is obviously not a very efficient way. If the task takes a long time, application will call the GetStatus interface multiple times during that time to get the task status information in a timely manner. This not only aggravates the burden of application, but also adds to the service burden. So, we can turn the dependency of this place on the other hand, let the service proactively notify the application of the task's state information. Accordingly, the service and application interfaces should also be changed accordingly:

For example, we changed the process of invoking the service's GetStatus interface originally from application to the SetStatus interface of the service call application. This enables the service to notify application in real-time as soon as the task state changes, thus reducing the two service-to-server unnecessary requests.

Question three:

If, after application invokes the service's AddTask interface, the server cannot respond to external requests for a variety of reasons. Then, when the task is finished, the service will not be able to feed this important state to application. And, because the service can't always try to call application's SetStatus interface until it succeeds. Then, how to get the state of the previous task when application is restarted becomes a problem. So, for this reason, the previous GetStatus interface actually has the necessary to exist.

With GetStatus this interface, if application has missed the service push task completion message after calling AddTask after the phenomenon has occurred. Then application can get the latest status of this task by itself through the service's GetStatus interface after restarting.

At this point, the API section has been designed.

About the interface part, at present I can think of the problem is so much, do not know that there is nothing missing or inappropriate. I hope you will be very grateful to enlighten me.

How to design an asynchronous Web service-Interface Section