HTTP GET для создания и получения «фонового» задания

Question

Я разрабатываю API для планировщика заданий.Есть один планировщик с некоторым набором ресурсов и таблицами БД для них.Также есть несколько «работников», которые запрашивают «задания» из планировщика.Работник не может создать работу, он должен только запросить ее.Работа должна быть рассчитана на стороне сервера.Также задание является динамической сущностью и рассчитывается с использованием нескольких таблиц БД и времени.Нет таблицы «заданий».

В целом эта система очень похожа на очередь задач.Но без очереди.Мне нужен метод для работника, чтобы запросить следующую задачу.Эта задача должна быть рассчитана и назначена для этого агента.

Можно ли использовать глагол GET для извлечения и «блокировки» задания для конкретного работника?С точки зрения ресурсов этот запрос ничего не меняет.Только внутреннее состояние БД обновляется.Для клиента это выглядит как выборка записей одна за другой.Он не знает о внутренних изменениях.

В чистом стиле REST мне, вероятно, следует определить таблицу заданий и CRUD API для нее.Затем мне нужно создать вспомогательный сервис для POST заданий для этой таблицы.Затем каждый агент выводит список заданий, используя GET, а затем блокирует его, используя PATCH.Этот подход требует многократных повторных попыток из-за условий гонки.(Работа может быть заблокирована другим агентом).Также это выглядит немного сложнее, если мне нужно назначить задание конкретному агенту на основе логики на стороне сервера.В этом случае мне нужно реализовать некоторую логику проверки на стороне клиента для итерации по заданиям, основанным на различных ответах.

Этот подход выглядит сложным.

Answer 1

Можно ли использовать глагол GET для извлечения и «блокировки» задания для конкретного работника?

Может быть? Но, вероятно, нет.

Важная вещь, которую нужно понять о GET, это то, что она безопасна

Целью разграничения безопасных и небезопасных методов является разрешить процессы автоматического поиска (пауки) и производительность кэша оптимизация (предварительная выборка) для работы без страха причинить вред. В Кроме того, он позволяет агенту пользователя применять соответствующие ограничения к автоматизированное использование небезопасных методов при обработке потенциально ненадежный контент.

Если агрессивная оптимизация производительности кэша создаст беспорядок в вашей системе, то GET - это не тот метод http, который вам нужен для запуска такого поведения.

Если бы вы проектировали взаимодействие вашего клиента с ресурсами, то у вас, вероятно, было бы что-то вроде списка заданий, назначенных работнику. Чтение текущего представления этого ресурса не требует, чтобы сервер изменил его, поэтому GET полностью подходит. И, конечно, сервер может обновлять этот ресурс по своим собственным причинам в любое время.

Запросы на изменение этого ресурса не должны быть безопасными. Например, если клиент собирается сообщить, что какое-то задание выполнено, это следует сделать небезопасным методом (POST / PUT / PATCH / DELETE /...)

У меня нет такого ресурса. Это эфимерный ресурс, который распространяется по столам. Для этого нет таблицы БД, и нет столбца ID для обновления этого задания. Это еще один вопрос, почему у меня нет такой таблицы, но это текущие требования и ограничения.

Достаточно справедливо, хотя главный урок все еще стоит.

Еще один способ думать об этом - думать о неудаче. Сеть ненадежна . В распределенной среде клиент не может отличить потерянный запрос от потерянного ответа. Все, что он знает, это то, что он не получил подтверждение запроса.

Когда вы используете GET, вы неявно говорите клиенту, что безопасно (снова это слово) переслать запрос. Не только это, но вы также неявно говорите любым промежуточным компонентам, что повторение запроса безопасно.

Если нет никаких неблагоприятных последствий для обработки нескольких копий одного и того же запроса, GET подойдет. Но если обработка нескольких копий одного и того же запроса стоит дорого, тогда вам, вероятно, следует использовать POST.

Не требуется , чтобы обработчик GET был безопасным - стандарт описывает только семантику сообщений; это не ограничивает реализацию вообще. Но любая потеря имущества , понесенная должным образом, считается ответственностью сервера.