Atomic Pipeline Configuration Update

[EndallBatan93]

• how do we handle API-Calls which are depending on each other
• enhance REST-API to post a batch of Configurations, Blueprints

[EndallBatan93]

• storing of configurations should not be the atomic operation
• the actual updating of the pipeline should be atomic. There we should handle if a configuration is missing and then either roll back or use the current configuration.

[MaxKarthan]

I think there are even more things regarding the REST-API we should consider: The current distinction between updating a resource and creating a new resource leads to unnecessary complexity in using the REST-API. I currently don't see the advantage of separating them. But at the moment I have to check every time before i want to update a resource if it is still there to use the correct method. Or I have to wait until the update failed and then send the creation request.

Also the separation into POST for update and PUT for creation might be appropriate but like mentioned here i think we could do better by using the defined idempotence property of the PUT Verb. I want to propose the following behavior:

1. Update and creation of a single resource is done via PUT, we can therefore guarantee that no matter how often that call is send the result will always be the same. What is exactly what we advertise to browsers etc. by using the PUT Verb. With the current API this is not true. If the resource does not exist, the response is different. If someone creates the resource in between two requests the result is not the same.

2. The planned post of a batch of configurations is done via POST. Here we cant define a concrete resource to create or update therefore the POST method should be used here. So at this point it wouldn't be possible to distinguish between update and creation anyway.

I know the first implementation of the API did not separate create and update. Maybe I'm missing the advantage but if I am, please enlighten me ;)

[kKdH]

I like the argument about idempotence. It sounds reasonable :

Better is to choose between PUT and POST based on idempotence of the action.

PUT implies putting a resource - completely replacing whatever is available at the given URL with a different thing. By definition, a PUT is idempotent. Do it as many times as you like, and the result is the same. x=5 is idempotent. You can PUT a resource whether it previously exists, or not (eg, to Create, or to Update)!

POST updates a resource, adds a subsidiary resource, or causes a change. A POST is not idempotent, in the way that x++ is not idempotent.

[kKdH]

With the experience from issue #6 we saw that we have to encode the kind of operation into the URL and add more information within the content to create a sophisticated REST api - Using different HTTP methods (POST, PUT, GET...) isn‘t enough.

I‘m going to close this issue because we have separated the workflow of storing and materializing pipelines.