GET Vs POST в REST
Используйте GET, если семантика GET соответствует варианту использования; другими словами, когда вы пытаетесь получить копию последнего представления некоторого ресурса.
Используйте POST, когда никакой другой стандартизованный метод не поддерживает нужную вам семантику.
Вы можете использовать POST для всего, но вы отказываетесь от преимуществ использования более специализированных методов - способности компонентов общего назначения делать разумные вещи, потому что они понимают семантику запроса. Например, GET имеет семантику безопасный , что означает, что компонент общего назначения знает, что он может предварительно получить представление ресурса до того, как оно понадобится пользователю, или автоматически повторить запрос, если он не получит ответ от сервера.
HTTP дает вам расширяемые коллекции уточнений метода POST общего назначения, добавляя дополнительные c ограничения, чтобы компоненты общего назначения могли использовать результирующие свойства.
Сложность URL-адреса
Сложность в URL-адресе на самом деле не имеет большого значения, поскольку для компонентов общего назначения URL-адрес просто непрозрачная последовательность байтов, которая подчиняется определенным правилам производства . По большей части эффективный целевой uri веб-запроса обрабатывается как единица atomi c, поэтому то, что может показаться "сложным для человека", вообще не беспокоит машины (например, взгляните на URL, используемый при отправке запроса с домашней страницы Google).
длина URL, которая может ограничить нас в будущем
Мы немного заботимся об URL length . RF C 3986 не ограничивает длину URI, но некоторые реализации компонентов общего назначения не работают, если длина выходит далеко за пределы нормы. Так что вы, вероятно, не захотите включать закодированный URL копия полных произведений Шекспира в части запроса вашего запроса.
Будущая область для включения любого нового поля
Опять же, здесь нет большой разницы. Добавление новых необязательных элементов в шаблон URI на самом деле ничем не отличается от добавления новых необязательных элементов к шаблону сообщения.
мы можем рисковать раскрыть параметры
* 1 048 * Мы также хотим быть осторожными с конфиденциальной информацией - для машин URI является идентификатором; нет особых причин беспокоиться о конкретной c последовательности байтов. Это означает, что URI может отображаться в неактивном состоянии (в истории клиентов или списке закладок в журналах доступа к серверам). Ограничение конфиденциальной информации телом сообщения снижает вероятность утечки данных за пределы их предполагаемого использования.
Обратите внимание, что REST и использование различных HTTP-методов - не единственный способ выполнить полезную работу. SOAP (и совсем недавно gRP C) решил, что другой набор компромиссов был лучше - по сути, сокращение HTTP до транспорта , а не приложения как такового .
Согласно Rest, мы должны ... использовать POST, если он создает ресурс.
Это неправильная интерпретация REST. Это очень распространенная интерпретация, но неверная. Семантика POST определяется RF C 7231; это означает это, а не что-то еще.
Предложение о том, что POST следует использовать только для создания, вводит в заблуждение по сравнению с упрощением. Самые ранние ссылки, которые мне удалось найти, - это сообщение в блоге Пола Прескода в 2002 году; и, конечно, он стал очень популярен с появлением Ruby на Rails.
Но помните: REST - это архитектурный стиль всемирной паутины. HTML, наиболее распространенный гипертекстовый тип мультимедиа, используемый в Интернете, имеет встроенную поддержку только двух методов HTTP; GET, используемый для получения представлений ресурсов с сервера, и POST, который выполняет все остальное .