Ответ 1

Вы не можете использовать API, используя POST или GET, если они не созданы для вызова с использованием этих методов по отдельности. Например, если ваш API говорит

/service/function?param1=value1&param2=value2

осуществляется с помощью метода GET. Тогда вы не можете вызвать его, используя метод POST, если его создатель не указал метод POST. Если вы сделаете это, вы можете получить статус 405 Method not allowed.

Как правило, в методе POST необходимо отправить содержимое в теле с указанным форматом, который описан в заголовке content-type для ex. application/json для данных JSON.

И после этого тело запроса десериализуется в конце сервера. Таким образом, вам нужно передать сериализованные данные от клиента, и это решает разработчик сервиса.

Но в общих чертах GET используется, когда сервер возвращает некоторые данные клиенту и не оказывает никакого влияния на сервер, тогда как POST используется для создания некоторого ресурса на сервере. Так что в целом это не должно быть одинаковым.

Ответ 2

Просто, чтобы просмотреть, REST имеет определенные свойства, которые должен выполнить разработчик, чтобы сделать его RESTful:

Что такое REST?

Согласно википедии:

Архитектурный стиль REST описывает следующие шесть ограничений применительно к архитектуре, оставляя при этом отдельные компоненты, которые могут быть разработаны:

• Клиент-сервер: Серверы не связаны с пользовательским интерфейсом или пользовательским состоянием, поэтому серверы могут быть более простыми и масштабируемыми.
• Безстоящий: Коммуникация клиент-сервер дополнительно ограничена отсутствием клиентского контекста на сервере между запросами.
• Cacheable: Ответы должны, неявно или явно, определять себя как кэшируемые или нет, чтобы клиенты не повторно использовали устаревшие или несоответствующие данные в ответ на дальнейшие запросы.
• Многоуровневая система: Клиент не может обычно указывать, подключен ли он непосредственно к конечному серверу или к посреднику на этом пути. Промежуточные серверы могут улучшить масштабируемость системы за счет включения балансировки нагрузки и предоставления общих кэшей.
• Код по требованию (необязательно): Серверы могут временно расширять или настраивать функциональные возможности клиента путем передачи исполняемого кода.
• Равномерный интерфейс:. Единый интерфейс между клиентами и серверами, рассмотренный ниже, упрощает и отделяет архитектуру, которая позволяет каждой части развиваться независимо. (т.е. HTTP GET, POST, PUT, PATCH, DELETE)

Что должны делать глаголы

Пользователь SO Daniel Vasallo проделал хорошую работу по определению ответственности этих методов в вопросе Общие сведения о REST: глаголы, коды ошибок и аутентификация:

При работе с URI коллекции, например: http://example.com/resources/

GET: Список членов коллекции, в комплекте с их членом URI для дальнейшей навигации. Например, перечислите все автомобили для продажи.

PUT: Значение, определенное как "заменить всю коллекцию на другую коллекция".

POST: Создайте новую запись в коллекции, где назначается идентификатор автоматически по коллекции. Созданный идентификатор обычно включается как часть данных, возвращаемых этой операцией.

УДАЛИТЬ: Значение, определенное как "удалить всю коллекцию".

Итак, чтобы ответить на ваш вопрос:

Можно ли сказать, что я могу использовать его с запросом POST?...

Являются ли эти два вопроса одинаковыми? Могу ли я использовать второй вариант в любом случае, или в документации должно быть указано, что я могу использовать как запросы GET, так и POST?

Если вы пишете простой старый вызов API RPC, они могут быть технически взаимозаменяемыми, если сторона сервера обработки не отличается от обоих вызовов. Однако для того, чтобы вызов был RESTful, вызов конечной точки с помощью метода GET должен иметь определенную функциональность (которая заключается в получении ресурсов (ов)) из метода POST (который должен создавать новые ресурсы).

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

Ответ 3

Я использую тело POST для любых нетривиальных и бизнес-приложений по следующим причинам:

• Безопасность. Если мы используем GET с цепочками запросов и https, строки запроса могут быть сохранены в журналах сервера и перенаправлены в качестве реферальных ссылок. Оба они теперь видны администраторами сервера/сети и следующим доменом, который пользователь отправил после выхода из вашего приложения. Поэтому, если мы отправляем запрос, содержащий конфиденциальные данные PII, такие как имя клиента, это может быть нежелательно.
• Максимальная длина URL - не большая проблема, но некоторые браузеры имеют ограничение по длине. Поэтому, если у нас есть несколько элементов в нашем URL-адресе, например запрос, пейджинг, поля для возврата и т.д....
• Пост не является кешем по умолчанию. Некоторые говорят, что кеширование желательно; однако, как часто это тот же самый набор критериев поиска для этого точного объекта для того, что именно этот клиент будет происходить до истечения времени кеша?

Кстати, я также помещаю поля в мой POST-модуль, поскольку я, возможно, не хочу показывать имена полей. Безопасность подобна луку; много слоев и заставляет нас плакать!

Ответ 4

Подумайте об этом. Когда ваш клиент делает запрос GET на URI X, то, что он говорит серверу: "Я хочу представить ресурс, расположенный в X, и эта операция не должна ничего менять на сервере". Запрос PUT говорит: "Я хочу, чтобы вы заменили все, что есть ресурс, расположенный в X, с новым сущностью, которую я даю вам в теле этого запроса". В запросе DELETE говорится: "Я хочу, чтобы вы удалили все ресурсы, расположенные в X". ПАРТ говорит: "Я даю вам этот diff, и вы должны попытаться применить его к ресурсу в X и сказать мне, если он преуспеет". Но POST говорит: "Я отправляю вам эти данные, подчиненные ресурсу в X, и у нас есть предыдущее соглашение о том, что вы должны с ним делать".

Если у вас нет документального документа, где ресурс ожидает POST и что-то делает с ним, нет смысла отправлять POST ему, ожидая, что он будет действовать как GET.

REST опирается на стандартизованное поведение базового протокола, а POST - это точно метод, используемый для не стандартизированного действия. Результат запросов GET, PUT и DELETE четко определен в стандарте, но POST - нет. Результат POST подчинен серверу, поэтому, если он не задокументировал, что вы можете использовать POST, чтобы сделать что-то, вы должны предположить, что вы не можете.

Ответ 5

Хорошо, что REST привносит смысл в глаголы HTTP (как они определены), но я предпочитаю согласиться со Скоттом Пилом.

Вот также элемент из расширенного объяснения WIKI по запросу POST:

Есть моменты, когда HTTP GET менее подходит даже для поиска данных. Примером этого может служить указание большого количества данных в URL. Браузеры и веб-серверы могут иметь ограничения по длине URL-адреса, который они будут обрабатывать без усечения или ошибки. Процентное кодирование зарезервированных символов в URL-адресах и строках запроса может значительно увеличить их длину, и хотя Apache HTTP Server может обрабатывать до 4000 символов в URL-адресе, [5] Microsoft Internet Explorer ограничен 2048 символами в любом URL-адресе. [6] Точно так же не следует использовать HTTP GET, если для завершения запроса необходимо предоставить конфиденциальную информацию, такую как имена пользователей и пароли, а также другие данные. Даже если используется протокол HTTPS, предотвращающий перехват данных при передаче, история браузера и журналы веб-сервера, скорее всего, будут содержать полный URL-адрес в виде открытого текста, который может быть раскрыт при взломе любой из систем. В этих случаях следует использовать HTTP POST. [7]

Я мог только предложить команде REST рассмотреть более безопасное использование протокола HTTP, чтобы потребители не боролись с небезопасной "хорошей практикой".

Ответ 6

В REST каждый HTTP-глагол имеет свое место и значение.

Например,

• GET - это получить "ресурс (ы)", на который указывает URL-адрес.

• POST заключается в создании инфраструктуры для создания "ресурса" типа, указанного в URL. Вы можете дополнить операцию POST параметрами или дополнительными данными в теле запроса POST.

В вашем случае, поскольку вас интересует "получение" информации, использующей запрос, таким образом, это должна быть операция GET, а не операция POST.

Эта wiki может помочь в дальнейшем прояснить ситуацию.

Надеюсь на эту помощь!

Ответ 7

POST допустимо использовать вместо GET, если у вас есть конкретные причины для этого и обработать его должным образом. Я понимаю, что это не совсем RESTy, но если в ваших данных есть куча пробелов, амперсандов и слешей и т.д. (Например, модель продукта, такая как Amazon), то попытка кодировать и декодировать это может оказаться более сложной задачей, чем просто предварительно озвучив это. Тем не менее, убедитесь, что вы возвращаете правильные коды ответов и тщательно комментируете то, что делаете, потому что это не типичный вариант использования POST.