Считается ли RESTful делать дополнительные вещи в API POST, кроме создания ресурса?

У нас есть API регистрации клиентов, который принимает имя, адрес электронной почты и мобильный телефон и генерирует идентификатор клиента, т.е.:

{ 
  "name": "john",
  "email": "[email protected]",
  "mobile": "+134325325" 
}

Мы создаем запись клиента для этого обращения к API. Клиент может быть создан из нескольких клиентов и форм. У нас есть новое требование: если мы получим эту запись о «создании клиента» из определенной формы, нам также необходимо отправить эту информацию (имя, адрес электронной почты, мобильный телефон) + (идентификатор клиента) в какой-либо сторонний API.

Я считаю, что согласно resful pratise, этот API должен создавать только «клиента» и не делать таких дополнительных вещей, которые будут действительны только для определенных клиентов/форм.

Что является лучшей альтернативой в этом случае:

  1. Создайте новый API для этого нового требования: этот новый API сначала создаст клиента, а затем отправит его стороннему API. Это соответствует нашему требованию, но логика создания клиентов теперь находится в двух API.
  2. Используйте существующий «API регистрации клиентов», добавив новый флаг: мы бы установили этот флаг из этих форм, где у нас есть это новое требование по отправке данных третьей стороне. Сначала мы создадим клиента, и если флаг установлен, мы также отправим эти данные сторонним API. Но является ли этот подход RESTful?
  3. Из этих форм, где нам нужно отправить данные в сторонний API, сначала отправьте запрос в «API регистрации клиентов» и получите идентификатор клиента, а затем отправьте эти данные в сторонний API: это будет медленным, поскольку нам придется ждать идентификатор клиента на клиентская сторона.

api rest restful-architecture
person Sahil Sharma    schedule 02.08.2017    source источник

Ответы (3)


arrow_upward
1
arrow_downward

POST часто используется как универсальный для действий, которые в противном случае не вписываются в правильный REST API. Массовое создание, обновление или удаление, объединение записей, вход в систему, копирование и т. д. — все это распространенные примеры. Но все остальное, что вам нужно сделать, что не соответствует PUT, GET или DELETE, обычно может быть перегружено с помощью POST. Просто убедитесь, что вы используете отдельный URL-адрес для каждого использования POST.

т.е. POST /foo должен создать foo, а POST /bulk_delete должен удалить несколько fooa на основе параметров запроса или формы.

person Flimzy    schedule 02.08.2017
comment
Немного запутался, вы предполагаете, что это должен быть подход 1 или 2? - person Sahil Sharma; 03.08.2017
comment
Я не уверен, потому что ваши подходы не имеют для меня смысла. Кажется, вы неправильно используете термин API, когда имеете в виду конечную точку? - person Flimzy; 03.08.2017

arrow_upward
0
arrow_downward

Я не чувствую, что здесь уместился бы отдельный ресурс. Давайте представим, что мы обсуждаем не API проектирование конечных точек, а простой class метод createCustomer. Предоставление новой конечной точки аналогично созданию нового метода перегрузки createCustomerSpecific. Это стиль RPC - количество методов будет расти.

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

Для меня ваш случай должен управляться чем-то вроде фабрики репозиториев: логика вашего приложения знает, какой репозиторий вызывать - простой CustomerRepository или CustomerWithNotificationRepository.

person Artem    schedule 14.08.2017

arrow_upward
0
arrow_downward

Я надеюсь, что владельцу этого вопроса может не понадобиться ответ на это. Но вот мои мысли.

Мои предположения приведены ниже,

У вас есть класс CustomerService, который содержит методы для выполнения операций CRUD с данными клиентов.

У вас есть конечная точка /api/customers(метод: POST), которая вызовет метод CustomerService.create() для создания сведений о клиенте в БД.

Ваш второй подход (небольшая модификация):

Я предпочитаю не создавать другую конечную точку, поскольку мы не делаем ничего другого, кроме вызова стороннего API. Следовательно, запрос JSON будет изменен, как показано ниже, для хранения дополнительных данных со стороны клиента.



    {
        "clientData": {
            "notify": "true"
        },
        "customer": {
            "name": "john",
            "email": "[email protected]",
            "mobile": "+134325325"
        }
    }

После создания клиента мы должны проверить, верно ли поле уведомления или нет. Если да, то будет вызван сторонний API с данными клиента для дополнительной обработки.

person Balachandar    schedule 03.10.2017