REST, как POST или PUT без полного объекта (@RequestBody) - PullRequest
Новая
       135

REST, как POST или PUT без полного объекта (@RequestBody)

0 голосов
/ 08 мая 2020

У меня есть Entity 'Vote' с полями: 

private Integer id;
private LocalDate date;
private LocalTime time = LocalTime.now();
private User user;
private Restaurant restaurant;

Я знаю, что для REST POST я желательно использовать такой шаблон ресурсов, как этот: 

/votes

и в случае обновления: 

/votes/{voteId}

Предположительно, я должен получить объект полного голосования в моем контроллере из внешнего интерфейса следующим образом: 

@PostMapping(consumes = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<Vote> create(@RequestBody Vote vote)

Но мне это не нужно для создания или обновления этого объекта, я только нужен restaurantId вроде этого: 

@PostMapping
public void create(@RequestParam int restaurantId) {
        voteService.create(SecurityUtil.getUserId(), restaurantId);
    }

Итак, будет ли правильный выбор использовать такой шаблон ресурсов, или я ошибаюсь?

Для POST создать: 

/votes?restaurantId=10

Для обновления PUT: 

/votes/{voteId}?restaurantId=10

Ответы [ 3 ]

0 голосов
/ 08 мая 2020

Почему бы не использовать параметры пути? Несколько странно передавать параметры получения в POST и PUT. 

@PostMapping("/{restaurantId}")
public void createPost(@NonNull @PathVariable(value = "restaurantId") String restaurantId) {
    voteService.create(SecurityUtil.getUserId(), restaurantId);
}

@PutMapping("/{restaurantId}")
public void createPut(@NonNull @PathVariable(value = "restaurantId") String restaurantId) {
    voteService.create(SecurityUtil.getUserId(), restaurantId);
}
0 голосов
/ 08 мая 2020

Итак, будет ли правильный выбор использовать подобный шаблон ресурса, или я ошибаюсь?

«Это зависит от ситуации».

Правописание URI не имеет значения для машин; /0d905ca3-c848-4bc5-bc4a-658fbec88ab5 - идеальный путь для использования. Человеческое написание - это просто удобство для людей - написание «RESTful» вроде /votes не больше REST, чем использование UUID, но когда операторы просматривают журналы, пытаясь идентифицировать шаблон трафика c, они будут вероятно, будет лучше второй вариант.

POST в качестве токена метода вполне подойдет. См. Это нормально использовать POST (Филдинг, 2009 г.).

PUT, однако, звучит не совсем так, как вы хотите. Семантически PUT означает «заменить текущее представление ресурса полезными данными текущего сообщения». Это метод удаленного создания , который в сочетании с GET дает вам хранилище документов:

PUT - это метод, который вы использовали бы в Интернете для редактирования своей домашней страницы. , например. 

GET /home-page

(make changes locally)

PUT /home-page

И тело этого запроса PUT является предполагаемой новой версией домашней страницы.

В вашем случае: 

PUT /votes/{voteId}?restaurantId=10

это Предполагается, что полезная нагрузка будет выглядеть так, как если бы вы сделали это 

GET /votes/{voteId}?restaurantId=10

Это должно быть полное представление ресурса.

Это не означает, что это должно быть полное представление сущности ; ресурсы - это обобщение документа; a просмотрите данные вашей организации. Удаленное создание отправляет новое представление представления, и задача сервера - внести соответствующие изменения в объект. См. Jim Webber 2011 .

Если вы не хотите делать обновления таким образом, это отлично - но тогда вам не следует использовать PUT, поскольку это лишает смысла иметь общее семанти c со всеми другими ресурсами (вы должны использовать POST).

0 голосов
/ 08 мая 2020

Вы должны изменить его на: 

@PostMapping
public void create(@RequestParam("restaurantId") int restaurantId) {
    voteService.create(SecurityUtil.getUserId(), restaurantId);
}

Вы должны указать имя параметра в @RequestParam ("param_name")

...