I've been given a task to design and develop some WebAPI services. I've never worked with WebAPI before. To keep it simple:
Service 1 will be invoked to retrieve, process and save thousands of objects. For each object, it calls Service 2 asynchronously
Service 2 performs some processing, creating multiple objects for each object passed in. There will be some delay here.
The pattern defined is to use an async WebAPI. Service 2 will capture the request, and return an ID to Service 1 before processing. Service 1 will then periodically call service 2 to check the status, and be returned either a completed status or a processing status, along with a hint time to check again. Service 1 will be processing hundreds or thousands of records at once.
To me this doesn't seem like the best pattern. I thought if we used true async WebAPI services, the callback into Service 1 would be handled by the framework, and there's no need to poll. Another option would be for Service 2 to call Service 1 when it is finished, passing in the details.
Any thoughts on this?