REST API для GET с @RequestBody

Question

Я пытаюсь следовать рекомендациям при создании конечной точки REST для моего ресурса Dashboard.Поэтому я планирую создать POST для создания, PUT для обновления и GET для получения Dashboard в моем весеннем контроллере MVC.

Однако у меня также есть конечная точка API validate, которая ничего не сохраняет и не обновляет в базе данных, поэтому я планировал использовать HTTP-метод GET для конечной точки validate.Но есть много параметров, которые мне нужно передать этой конечной точке, поэтому я бы предпочел, чтобы это был @RequestBody, а не просто обычный параметр запроса, потому что GET имеет предел, который я могу превысить.

Стоит ли использовать POST вместо GET, хотя я не планирую вносить какие-либо изменения в базу данных?

@PostMapping("/dashboards/{id}/validate")
public ResponseEntity<VisualMetadata> validateVisualMetadata(@PathVariable String id,
                                                             @Valid @RequestBody DashboardDto requestDto) {
}

UPD: DashboardDto не просто имеет примитивы, такие как String / long/ integer, но также имеет вложенные сложные типы данных, такие как Axis и Metric

class DashboardDto {
   String id;
   Axis axis;
   List<Metric> metrics;
}

Answer 1

Стоит ли использовать POST вместо GET, хотя я не планирую вносить какие-либо изменения в базу данных?

Возможно.Иногда в реестре HTTP-метода можно найти менее распространенный стандартизированный метод, который подходит для вашего случая использования.Принимая во внимание, что нет никаких предполагаемых изменений в состоянии ресурса, вы бы искали безопасный метод.

Я не думаю, что есть подходящий вариант для вашего варианта использования.

Но отправка запроса GET с телом сообщения (как правило) является плохой идеей:

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

Отчасти дело в том, что несколько организаций могут использовать стандартизированные готовые решения, и все «просто работает».Если вам не нужно это обещание (ваша организация контролирует клиента, сервер и компоненты между ними), вам, возможно, удастся сойти с рук.По крайней мере, на какое-то время.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *] * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *} * 10 * *Промежуточные компоненты не обязательно будут знать, что запрос безопасен, поэтому он не идеален (например, промежуточные компоненты не будут знать, что безопасно переслать запрос, если ответ потерян).