Простые конечные точки CRUD Vs. более сложные конечные точки

Question

У нас была дискуссия с коллегой (фронтэндом) о том, чья ответственность должна заключаться в том, чтобы справляться со сложностью, и мы действительно не пришли к выводу.

Основная идея: чья ответственность должна заключаться в том, чтобы справляться со сложностью - должен ли бэкэнд иметь дополнительные более сложные конечные точки, объединяющие несколько простых существующих конечных точек, или клиент (внешний интерфейс) должен делать несколько вызовов простых конечных точек?

Пример пары:

Восстановление ключей API

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

С точки зрения коллеги - должна быть конечная точка, которая объединяет эти 2 действия в одно, потому что было бы проще отменить изменения, если второе действие (Добавить ключ) завершилось неудачей.

Другой пример - когда пользователь регистрируется, мы создаем для него несколько вложенных объектов, что-то вроде

Parent ⮑Child ⮑GrandChild

Моя идея еще раз - простые конечные точки для операций CRUD и их цепочка (3 вызова), и у моего коллеги есть одно мнение о том, как обрабатывать сбой, если один из них дает сбой.

Answer 1

Сложность обработки на клиенте или сервере зависит от реальных вариантов использования, которые вы пытаетесь разработать.

Отвечая на регенерацию KEY из указанного вами образца, Регенерация подразумевает, что старый ключ должен быть удален, а новый действительный ключ должен быть возвращен. В случае неудачи 2-го, первая модификация должна быть возвращена в ваш бэкэнд. то есть оба шага должны рассматриваться как одна транзакция . Если это не так, достаточно иметь отдельные API.

Другой пример: если есть n ресурсов, которые нужно удалить, клиент может вызвать / resources / $ resource_id - HTTP DELETE в цикле, который, в свою очередь, может попасть в вашу БД. n раз. Поэтому, учитывая оптимизацию внутренних ресурсов, лучше всего поддерживать удаление нескольких ресурсов в одном API. Пример: / resources? Ids = 1,2,3,4 - УДАЛЕНИЕ HTTP

Answer 2

кто несет ответственность за управление сложностью - должен ли бэкэнд иметь дополнительные более сложные конечные точки, объединяющие несколько простых существующих конечных точек, или клиент (внешний интерфейс) должен делать несколько вызовов простых конечных точек?

Если сомневаешься - загляни в сеть. Вы думаете, что поиск в Google прост? как насчет заказа в один клик на Amazon?

REST, в целом, предназначен для маскировки деталей вашей реализации за фасадом веб-сайта / магазина документов. Это в значительной степени не зависит от того, делаете ли вы эту маскировку простой или сложной.

Взгляните на выступление Джима Уэббера о REST с моделями доменов .