Каков будет подходящий подход к выполнению требований при соблюдении принципов REST?
REST не имеет значения, какое написание используется для идентификаторов ресурсов.
Есть две вещи, которые вы должны иметь в виду.Во-первых, эталонное приложение для архитектурного стиля REST - это всемирная паутина, которая прекрасно справляется только с GET и POST.Во-вторых, что кэширование является важной частью этой истории.
В HTTP, когда сервер возвращает код состояния без ошибок в ответ на небезопасный запрос, это неявная инструкция дляклиент (и любые промежуточные компоненты), которые ранее кэшировали представления, должны быть признаны недействительными.
Поэтому мы обычно хотим организовать, чтобы правки были небезопасными запросами к наиболее важному ресурсу, который должен бытьобновляется, если изменение прошло успешно.
Так, если я хочу получить отчет вместе с его метаданными?
GET /A3E7205B-6DC6-4685-9133-2759F739BC22
Если я хочу получить метаданные без самого отчета?
HEAD /A3E7205B-6DC6-4685-9133-2759F739BC22
Если я хочу изменить отчет
POST /A3E7205B-6DC6-4685-9133-2759F739BC22
PUT и PATCH являются допустимыми альтернативами POST с более конкретной семантикой, поэтому их можно использовать там.
С точки зрения REST, create - это просто еще один вид edit :
Ресурс может отображаться на пустой набор, которыйпозволяет ссылки на бЭто делается до того, как какая-либо реализация этой концепции существует - Fielding
Но часть общей гибкости POST заключается в том, что он поддерживает создание ресурса с другим идентификатором.Так что вы можете сделать это, если хотите,
, если отчет не существует;отчет об инициализации и возврате
Семантика GET должна быть безопасной - кэшам разрешено улучшать работу с помощью предварительной загрузки ресурсов, паукам разрешено их сканировать и так далее.Это не значит, что вы не можете создать что-то - HTTP ограничивает вашу семантику, а не вашу реализацию - только то, что вам нужно знать о последствиях.
HTTP не пытается требовать, чтобы результаты GET были безопасными.Для этого требуется, чтобы семантика операции была безопасной, и, следовательно, это ошибка реализации, а не интерфейса или пользователя этого интерфейса, если в результате произойдет что-либо, что приведет к потере свойства - Филдинг 2002
Вы заметили:
POSTING ... пустое тело в конечную точку кажется неправильным
Нет, этохорошо, правда.Вам нужно будет продумать некоторые другие варианты использования (что означает POST пустое тело для отчета, который существует?)
Но в случае, когда создание нового отчета эффективно бесплатно,а клиенту не нужно знать о деталях?Затем просто скажите клиенту GET представление и создайте то, что вам нужно по запросу.