Как правильно использовать методы HTTP-запроса в REST API? - PullRequest
Новая
       33

Как правильно использовать методы HTTP-запроса в REST API?

0 голосов
/ 07 марта 2019

В своем поиске, чтобы понять методы HTTP-запроса, особенно PUT, поскольку я, по-видимому, неправильно все это использовал, я наткнулся на множество цитат, в которых говорится «PUT не относится к REST API» и «Следует использовать GET и POST только в современных API» .

Это просто заставляет меня задуматься, почему бы вам не использовать PUT, PATCH, DELETE и т. Д. В API REST? Разве это не то, для чего они там? Быть использованным, потому что они помогают с семантикой и структурой и т.д.?

Может ли это быть как-то связано, например, с методы, получающие запрос, в основном являются методами, которые направляют данные другим методам, таким как методы базы данных, где они затем обрабатываются? Я использовал PUT, когда хотел обновить документ, но никогда не перезаписывал документ, хотя я отправил на него только часть данных.

Ниже приведен пример этого с использованием Express и MongoDB (с указанием метода put в Express). 

app.put('/users/:id', (req, res, next) => {
    let id = req.params.id;
    userService.getOneUser({_id: ObjectID(id)}).then((user) => {

        let updatedData = req.body;

        userService.updateUser(user._id, updatedData)
           .then((doc) => res.json(doc))
           .catch((err) => errorHandler(err, res, next));

    }).catch((err) => errorHandler(err, res, next));
})

В основном мой вопрос таков: В отношении вышеприведенных утверждений, как вы правильно используете эти методы в REST API и когда вы их используете?

РЕДАКТИРОВАТЬ: Пример с двумя ссылками:

PUT не входит в REST API

Используйте только GET и POST - см. Третий комментарий к вопросу

1 Ответ

1 голос
/ 07 марта 2019

Я наткнулся на множество цитат, в которых говорилось, что «PUT не относится к API REST» и «В современных API нужно использовать только GET и POST».

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

Я бы предложил начать с Джим Уэббер , который хорошо понимает.

HTTP - это протокол приложения, доменом приложения которого является передача документов по сети.

PUT, PATCH, DELETE - все это прекрасные методы для описания изменений в документе. Я GET документ от вас, я использую мой любимый HTTP-редактор / библиотека для внесения изменений в документ, я отправляю вам запрос с описанием моих изменений в документе, вы получите понять, что делать с вашей стороны.

Это просто заставляет меня задуматься, почему бы вам не использовать PUT, PATCH, DELETE и т. Д. В API REST? Разве это не то, для чего они там? Быть использованным, потому что они помогают с семантикой и структурой и т.д.?

Одна из причин, по которой вы можете этого не делать: ваш тип мультимедиа - HTML - HTML имеет встроенную поддержку ссылок (GET) и форм (GET / POST), но не так много прямой поддержки в привлечении других методы в потоке. Вы можете использовать код по требованию для тех клиентов, которые его поддерживают.

Может ли это быть как-то связано, например, с методы, получающие запрос, в основном являются методами, которые направляют данные другим методам, таким как методы базы данных, где они затем обрабатываются? Я использовал PUT, когда хотел обновить документ, но никогда не перезаписывал документ, хотя я отправил на него только часть данных.

Важная вещь, которую нужно понять о методах HTTP, заключается в том, что они описывают семантику, а не реализации. Вот Написание поля в 2002 :

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

В конкретном случае PUT есть дополнительный намек на смысл семантики

Успешное PUT данного представления предполагает, что последующее GET для того же целевого ресурса приведет к отправке эквивалентного представления в ответе 200 (ОК). Тем не менее, нет никакой гарантии, что такое изменение состояния будет наблюдаемым ....

Я думаю, что Трийнко поднимает хороший вопрос:

URI, идентифицированные в большинстве современных приложений, НЕ являются ресурсами, подлежащими замене, обновлению и т. Д. Они не являются документами. Они называются ПРОЦЕДУРАМИ.

Если вы создаете API с процедурой , в отличие от API с ресурсом , то существует большая вероятность того, что PUT / PATCH / DELETE на самом деле не дают преимуществ что оправдывает дополнительную сложность.

Один намек на то, что вы сосредоточены на процедурах: сколько внимания вы уделяете аннулированию кэша ? Частью принятия ограничения «единого интерфейса» является то, что вам нужны возможности, которые могут предоставить универсальные компоненты, а в HTTP кеширование имеет большое значение.

...