Дизайн методов обновления ресурса в CRUD REST-сервисах

Дизайн методов обновления ресурса в CRUD REST-сервисах.

Во многих проектах ставится задача организовать доступ к ресурсу через REST API в т.ч. реализовать методы для обновления ресурса. К сожалению из-за отсутствия стандарта обновление ресурса зачастую до сих пор ассоциируется только с HTTP методом PUT.

В своем докладе я расскажу:
1. Почему HTTP PUT в общем случае — не лучший метод для обновления ресурса. В каких случаях его действительно нужно применять.
2. Об HTTP методе PATCH.
3. Об HTTP методе POST для обновления ресурса.
4. О проблеме параллельного обновления ресурса.

План:
1. HTTP PUT.
1.1. HTPP PUT — замена ресурса по указанному адресу.
1.2. Ограничения HTTP PUT // Расширения состава атрибутов влечет правку клиентов, идемпотентность, кэширование. Практические грабли, если проигнорировать ограничения: Nginx, Chrome.
1.3. Когда действительно стоит использовать HTTP PUT. // Пример с книжной полкой, пример с избранным.

2. HTTP PATCH.
2.1. HTTP PATCH — частичное обновление ресурса.
2.2. JSON Patch.
2.3. Пример JSON Patch.
2.4. JSON Merge Patch.
2.5. Пример JSON Merge Patch.
2.6. HTTP PATCH — универсальный метод для обновления ресурса.

3. HTTP POST для обновления ресурса.
3.1. Пример с асинхронным обновлением. // Пример с обновлением физически занимающем минуты.
3.2. Пример обновлением-бизнес-операцией. // Пример с неявным изменением состояния документа.

4. Проблема параллельного обновления ресурса.
4.1. Описание проблемы. // 2 клиента обновили один и тот-же ресурс и оба подумали, что их данные попали на сервер. Пример — задача в трекере с атрибутом «assignedTo».
4.2. Решение проблемы с помощью ETag и If-Match.

Презентация

Конференция Yappi Days 17