RESTful реализация шаблона проектирования метода фабрики

Question

Как бы вы разработали RESTful API для класса, который использует шаблон метода фабрики для создания объектов?

Допустим, у вас есть класс Passport:

public class Passport {
   final String firstName;
   final String lastName;
   final Date   birthDate;
   State  state;

   private Passport(State state, String firstName, String lastName, Date birthDate) {
      this.state = state;
      this.firstName = firstName;
      this.lastName = lastName;
      this.birthDate = birthDate;
   } 


   public static Passport createPreliminary(String firstName, String lastName, Date birthDate) {
       return new Passport(PRELIMINARY, firstName, lastName, birthDate);
   }

   public static Passport createRegular(String firstName, String lastName, Date birthDate) {
       return new Passport(REGULAR, firstName, lastName, birthDate);
   }

   public void invalidate() {
      state = INVALID;
   }
}

public enum State {
    PRELIMINARY,
    REGULAR,
    EXPIRED,
    INVALID
}

Экземпляр Passport может бытьсоздан в двух разных штатах.После создания только свойство состояния может быть изменено ограниченным способом с помощью методов перехода состояния, таких как invalidate ().

Каким будет RESTful способ создания ресурсов Passport?POST to / passports, включая свойство состояния, и проверить на стороне сервера, что состояние является РЕГУЛЯРНЫМ или ПРЕДВАРИТЕЛЬНЫМ, и вернуть ответ BAD REQUEST, если это недопустимое состояние?Или два разных URL для создания паспортных ресурсов, один для «обычных» и один для «предварительных» паспортов?

Answer 1

POST to / passports, включая свойство состояния, и проверить на стороне сервера, что состояние является РЕГУЛЯРНЫМ или ПРЕДВАРИТЕЛЬНЫМ, и вернуть ответ BAD REQUEST, если это недопустимое состояние?

Это вариант, который я бы выбрал. Наличие одной конечной точки для добавления в ресурс паспорта является самым простым и простым для понимания.

Если вы использовали другую опцию, каждый раз, когда вы добавляли / меняли элемент в перечисление «State», вам также приходилось изменять структуру ресурсов. Это просто вносит ненужную сложность и делает ваш дизайн API менее гибким.

Ваш API должен быть абстракцией вашей внутренней бизнес-логики. Не делайте его сложным и многослойным, если вам не нужно.