REST API, содержащий POST и PUT / PATCH, вызывающий вычислительный сервер, генерирующий файлы результатов

Question

Серверное приложение, которое я внедряю, генерирует результаты расчетов и сохраняет их в файлах результатов в каталогах на сервере.Например, клиент / проект / сценарий / файл результатов.Я хочу спроектировать и реализовать гибкую реализацию REST для извлечения файлов результатов для отображения в браузере клиента, удаления файлов результатов, клиентов и т. Д., А также для создания файлов результатов в сценарии для параметров расчета, отправляемых на сервер.И, возможно, провести анализ чувствительности, чтобы сгенерировать файлы результатов в сценарии путем изменения параметров расчета.

Я могу использовать GET для извлечения этих файлов, используя URL-адрес со строкой запроса appname /? CustomerId = xxx & projectId = xxx и т. Д. И DELETE для структуры каталогов и файлов, также используя строки запроса.Что мне неясно, так это лучший подход REST для вызова функций, реализующих различные вычисления на сервере.

Возможно, это должно быть POST для начального вычисления в сценарии, так как это создает файлы результатов?Может быть, PUT или PATCH для анализа чувствительности или других частичных перерасчетов, поскольку это приводит к изменению результатов в существующем сценарии?

Существует довольно много онлайн-дискуссий о PUT против PATCH против POST, используемых для операций, связанных с базой данных.Я мог бы разработать подход REST, основанный на том, что я прочитал для взаимодействий с базой данных REST, но если уже есть стандартная практика выполнения вычислений через REST API, я бы лучше использовал это.

Answer 1

Возможно, это должен быть POST для начального расчета в сценарии, поскольку это создает файлы результатов?Может быть, PUT или PATCH для анализа чувствительности или других частичных пересчетов, так как это приводит к изменению результатов в существующем сценарии?

Вы можете всегда просто использовать POST.Если бы мы использовали HTML-представления ресурсов для руководства клиента по протоколу, мы бы делали это, следуя ссылкам и отправляя формы.В HTML отправка форм ограничена GET и POSt.

PUT и PATCH имеют более жестко ограниченную семантику, чем POST.В частности, это методы, которые запрашивают, чтобы сервер сделал свое представление соответствующим представлению клиента (для PUT мы отправляем полное представление замены; для PATCH мы просто отправляем изменения, сделанные клиентом).

Технически,нет ничего плохого в том, что сервер не принимает предложенные изменения как:

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

Таким образом, сервер мог принять изменения клиента, а затем немедленно применить дополнительные изменения собственного.