1 Конечная точка службы против 3 отдельных конечных точек для создания / обновления / удаления в CRUD | Архитектура

Question

У меня вопрос по поводу создания служб CRUD, я должен иметь возможность создавать, обновлять, удалять и получать записи из БД.

Для простоты понимания. Я буду использовать пример компании, которой я должен написать услуги для выполнения CRUD. Я должен добавить сотрудника, обновить сотрудника, удалить сотрудника, получить список сотрудников, которые работают в компании.

Приведенный ниже объект будет использоваться в качестве полезной нагрузки для Create / Update / Delete , а список EmployeeDomainObject будет использоваться в качестве ответа для Get запроса

EmployeeDomainObject { "firstName": "string", "lastName": "string", "id": "string", "status": "ACTIVE" or "DELETE" or null }

• Должен ли я пойти с 2 службами?
  • 1 конечная точка для Получение для получения списка на основе идентификатора компании
  • 1 конечная точка для Создать / Обновить / Удалить , которая примет EmployeeDomainObject в качестве тела запроса и обновит БД соответственно на основе состояния.
    • Если запрос имеет статус: ноль -> Новый идентификатор записи будет нулевым, при сохранении будет сгенерирован один динамический идентификатор
    • Если запрос имеет статус: «ACTIVE» -> Обновить запись на основе идентификатора
    • Если запрос имеет статус: «УДАЛИТЬ» -> Удалить запись на основе идентификатора
• Должен ли я пойти с 4 услугами?
  • 1 конечная точка для Получите , чтобы получить список на основе идентификатора компании
  • 1 конечная точка для Создать , чтобы создать сотрудника на основе EmployeeDomainObject
  • 1 конечная точка для Обновление для обновления сотрудника на основе идентификатора в EmployeeDomainObject
  • 1 конечная точка для Удалить для удаления сотрудника на основе идентификатора в EmployeeDomainObject

Объем и требования услуг: 1. Надежность 2. Ремонтопригодность 3. Какой сервис больше ориентирован? 4. Масштабируемый / расширяемый

Ответы оценены

Answer 1

Это действительно зависит от того, как вы планируете внедрить услугу. Если вы собираетесь использовать установленный фреймворк, такой как Spring, то вы, скорее всего, будете использовать метод 4-й конечной точки и не иметь поля status, так как состояние будет подразумеваться глаголом HTTP (GET / POST / PUT / DELETE ).

На самом деле у вас есть RPC (удаленный вызов процедур). Поле status является «методом» для вызова. Там, где чистый REST будет использовать HTTP-глаголы, RPC будет использовать этот тип вызова метода. Поэтому, если вы планируете создавать сервис с нуля без использования инфраструктуры, вы можете использовать одну конечную точку. Я не вижу смысла иметь только 2 конечных точки, когда вы можете добавить другое поле status:

EmployeeDomainObject 
{
   "firstName": "string",
   "lastName": "string",
   "id": "string",
   "status": "ACTIVE" or "DELETE" or "RETRIEVE" or null 
}

и используйте POST. Это не ОТДЫХ, но вы не спрашиваете, хорошо ли это ОТДЫХ или нет.

Нет ничего «неправильного» в использовании вышеприведенного, особенно если вы собираетесь создавать сервис с нуля (возможно, он ограничен в ресурсах и т. Д.).

Конечные точки - это просто способ взаимодействия клиента со службой. Независимо от того, поступают ли эти взаимодействия через 4 конечных точки в стиле REST или 1 POST в стиле RPC, не имеет значения. Клиент просто делает то, что ему нужно.

Последствия для сервера. Установленная среда REST, такая как Spring, даст вам хорошее начало, но свяжет вас с 4 конечными точками. Если вы можете свободно проектировать серверную часть, тогда в подходе RPC-стиля нет ничего плохого. Вы по-прежнему можете регистрировать / проверять / обрабатывать разрешения для службы, но вам, вероятно, придется кодировать их самостоятельно.

Если вы планируете создавать что-то большое и нанимать много программистов, то вы, вероятно, захотите пойти по течению и использовать 4 конечных точки в стиле REST и устоявшуюся среду для найма более широкого круга талантов. пул, а не наем и обучение по вашей системе, разработанной на заказ.