CODEWITHSUNDEEP
servicerestful-architectureidempotent
Whimsical
Whimsical

Reputation: 6355

Service which provides an interface to an async service and Idempotency violation

Please keep in mind i have a rudimentary understanding of rest and building services. I am asking this question mostly cause i am trying to decouple a service from invoking a CLI(within the same host) by providing a front to run async jobs in a scalable way.

I want to build a service where you can submit an asynchronous job. The service should be able to tell me status of the job and location of the results.

APIs
1) CreateAsyncJob
Input: JobId,JobFile 
Output: 200Ok (if job was submitted successfully)

2) GetAsyncJobStatus
Input: JobId 
Output: Status(inProgress/DoesntExist/Completed/Errored)

3)GetAsyncJobOutput
Input: JobId 
Output: OutputFile

Question The second API, GetAsyncJobStatus violates the principles of idempotency.

Upvotes: 0

Views: 347

Answers (1)

Prahalad Deshpande
Prahalad Deshpande

Reputation: 4767

Based on the link here idempotency is a behaviour demonstrated by an API by producing the same result during it's repeated invocations.

As per my understanding idempotency is at per API method level ( we are more concerned about what would happen if a client calls this API repeatedly). Hence the best way to maintain idempotency would be to segregate read and write operations into separate APIs. This way we can reason more throughly with the idempotent behavior of the individual API methods. Also while this term is gaining traction with RESTful services, the principles hold true even for other API systems.

In the use case you have provided the response to the API call made by the client would differ (depending upon the status of the job).Assuming that this API is read-only and does not perform any write operations on the server, the state on the server would remain the same by invoking only this API - for e.g. if there were 10 jobs in the system in varied states calling this API 100 times for a job id could result in different status every time for the job id (based on it's progress) - however the number of jobs on the server and their corresponding states would be the same.

However if this API were to be implemented in a way that would alter the state of the server in some way - then this call is not necessarily idempotent.

So keep two APIs - getJobStatus(String jobId) and updateJobStatus(String jobId). The getJobStatus is idempotent while updateJobStatus is not.

Hope this helps

Upvotes: 1

Related Questions