Метод REST для создания нового ресурса с использованием POST

Question

1. Я хочу создать новый ресурс, используя POST в / users { «Имя»: «мистер Woods», «Возраст»: 29 }

2. У меня нет идентификатора в запросе.

3. Сервер создаст новый ресурс с автоматически сгенерированным идентификатором (даже существуют те же данные с другим идентификатором, что и должно быть), скажем, 1234

4. Новое местоположение ресурса / users / 1234 должно быть возвращено в ответе

5. Теперь я должен просто вернуть новый идентификатор в качестве возвращаемого значения в ответе или новый идентификатор, установленный во входном запросе, и вернуть всю сущность? { «Id»: 1234, «Имя»: «мистер Woods», «Возраст»: 29 }

6. Кроме того, когда запрос попадает в POST / пользователей, но у него уже есть идентификатор, предоставленный во входных данных, нужно ли проверять, чтобы это значение было нулевым, прежде чем создавать новый? Каким будет код ответа Http в этом случае, если на входе присутствует идентификатор?

Answer 1

У меня нет идентификатора в запросе.

Вам НЕ нужен. Вы можете просто использовать Db-SDK для этого.

Новое местоположение ресурса / users / 1234 должно быть возвращено в ответ

Было бы лучше сделать систему, управляемую гипермедиа HATEOS

Теперь я должен просто вернуть новый идентификатор в качестве возвращаемого значения в ответе или новый идентификатор установить во входном запросе и вернуть всю сущность? { «Id»: 1234, «name»: «г-н Вудс »,« возраст »: 29}

Как я уже сказал, хорошо возвращать полную информацию о гипермедиа, чтобы клиенты могли ссылаться на них без каких-либо дальнейших изменений для выполнения каких-либо повторных запросов

{
    "id": 1234,
    "name": "Mr.Woods",
    "age": 29,
    "address": "/1234/address",
    "some-param": "/path-to-the-resource"
}

Кроме того, когда запрос попадает в список POST / пользователей, но ему уже предоставлен идентификатор во входных данных, мы должны проверить, чтобы это было нулевым, прежде чем создаете новый?

В идеале вы должны проверить его, если вы следуете HTTP спецификациям. Пост должен всегда приводить к созданию ресурса. однако это просто следование спецификации, ничто не остановит вас, если вы хотите сделать свой POST идемпотентным

Answer 2

Теперь я должен просто вернуть новый идентификатор в качестве возвращаемого значения в ответе или новый идентификатор установить во входном запросе и вернуть всю сущность? { «Id»: 1234, «name»: «г-н Вудс »,« возраст »: 29}

Успешный запрос Rest POST не обязательно должен иметь тело ответа, в общем, если это точно те же данные, которые указаны в запросе + созданный идентификатор.
Ответ 201 Created, содержащий в location header URI созданного ресурса, выглядит нормально.

Это не означает, что запрещено указывать тело в ответе POST, просто вы должны устанавливать его только в том случае, если это добавляет какую-то дополнительную ценность для клиента.
Например, предположим, что создание ресурса может изменить данные, предоставленные клиентом (очистка, вычисления и т. Д.), Может иметь смысл установить ресурс в ответе тела.

Кроме того, когда запрос попадает в список POST / пользователей, но ему уже предоставлен идентификатор во входных данных, мы должны проверить, чтобы это было нулевым, прежде чем создаете новый? Каким будет код ответа Http в этом случае когда идентификатор существует на входе?

Это зависит от того, как вы хотите, чтобы ваши службы отдыха вели себя:

• Либо вы решаете, что обновление разрешено с помощью POST: в этом случае, если идентификатор null, вы создаете ресурс, а если нет null, вы обновляете ресурс, и если все в порядке, вы можете возврат 202 Accepted.
• Или вы решаете, что обновление не разрешено с POST: в этом другом случае, если идентификатор не null, вы возвращаете ответ об ошибке, такой как 400 Bad Request.

Answer 3

Я бы использовал пружинные hateoas (https://spring.io/projects/spring-hateoas), и я бы создал объект, подобный этому:

public class User extends ResourceSupport {
    private Long id;
    private int age;
    private String name;
    //Setter and getter and eventually hashCode and equals
}

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

@RequestMapping(value="/users", method={RequestMethod.POST}, produces="application/json")
public ResponseEntity<User> managePerson(@RequestBody User p)
{
  if(p.getId() != null)
  {
    //Update; in this case a 204 http status is enough and no content is required
   Return ResponseEntity.status(HttpStatus.NO_CONTENT).body(null);
  }
  else
  {
   //Save and return the saved objecty with the returned ID and set the new location
   p.add(new Link("/users/"+p.getId()));
   Return ResponseEntity.status(HttpStatus.OK).body(p);
  }

}