PUT & POST при написании API — Хабр Q&A

Кратко: POST — создание, PUT — обновление
Авторитетного источника применительно к REST не будет, так как REST, строго говоря, не определяет ни POST, ни PUT. REST просто допускает использование HTTP. Следовательно наиболее авторитетный источник по поводу POST/PUT — это спецификация HTTP 1.1:

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.

The PUT method requests that the enclosed entity be stored under the supplied Request-URI.

То есть POST используется для создания подчиненной сущности, а PUT для сохранения сущности.
POST в случае успеха всегда должен возвращать статус 201 (Created) и Location на новый ресурс.
PUT же может возвращать как 201 (если ресурс не найден), так и 204 (No Content) — если ресурс обновлялся.

Ответ написан

POST запрос подразумевает создание записи, результатом ее должены быть пустое тело ответа и заголовок location c uri нового объекта.

PUT — подмена записей. Тобиш обновить одно какое-то поле у записи нельзя. Опять же, если вы заменили объект — то вы уже имеете на руках все нужные данные, посему ответом может быть опять же заголовок location.

есть еще метод PATCH, который позволяет именно обновлять запись (конкретное поле или несколько из них). Тут тоже подразумевается возврат только URI. По сути какие либо данные вам может вернуть только GET запрос.

И есть еще куча заморочек со статус кодами, мол 200 это хорошо только для GET, так как оно имеет тело ответа. А для большинства других нужен 204, который говорит что все хорошо, но есть только заголовки.

НО… это если по феншую и именно RESTFull, причем это далеко не все. Обычно дальше GET/POST/PUT/DELETE никто не идет… PATCH вообще редко используют, а вот LINK вообще ниразу не видел что бы на реальных проектах применяли…

Ответ написан

более трёх лет назад

Комментировать

рекомендую вам не очень парится по поводу теории, а просто ограничиться POST и GET. В нашем проекте сделали всё по правилам, а потом выяснилось, что Флекс-код с другого сервера ни PUT, ни DELETE слать не может, пришлось делать проксирование.

Ответ написан

Комментировать

Ориентируетесь на это описание: microformats. org/wiki/rest/urls

Ответ написан

PUT должен быть идемпотентной операцией, т.е. несколько одинаковых последовательных пут-запросов на один урл (и с одинаковыми параметрами) не должны создавать новых объектов.

POST, в свою очередь, может создавать новые объекты при последовательных запросах на один урл.

Другими словами, POST нужно использовать для обращения к «производящим фабрикам».

Первая подручная статья, в которой это объясняется: на английском.

И да, PUT можно сравнить с INSERT… OM DUPLICATE KEY UPDATE.
POST — это чистый INSERT.

Ответ написан

PUT — создать новую запись
POST — обновить существующую запись

Ответ написан

2012, в 20:06″> более трёх лет назад

1. Как мне кажется наиболее эффективный метод работы выглядит следующим образом
GET /reports(.:format) reports#index (коллекция)
GET /reports/:report_id/images image#index (коллекция)
POST /reports(.:format) reports#create (создание)
GET /reports/new(.:format) reports#new (инициализация, удобный прием, в разрезе REST можно не рассматривать)
GET /reports/:id/edit(.:format) reports#edit (иницаилизация, данные для редактирования)

GET /reports/:id(.:format) reports#show (конкретный объект)
PUT /reports/:id(.:format) reports#update
DELETE /reports/:id(.:format) reports#destroy
DELETE /reports/:report_id/images images#destroy
PUT для коллекций ниразу не пришлось использовать, выдумывать ничего не буду

2. Вторая часть рест — коды ошибок
Например эффективно используется в связке с jQuery: евенты success, error и т. д. отзываются корректно.

3. (самое важное) Межсистемное взаимодействие.
Restfull API интуитивно понятен разработчикам сторонней системы, если конечно разработчики представляют что такое рест

В любом случае, при межсистемном взаимодействии, важно пользоваться единым стандартом, а разрабатывать его налету — опасно. Большинство выбрали REST, если я не заблуждаюсь.

4. Никакой путаницы.
Ни в приложении, ни во фронтенде, ни в API, при использовании REST, вы совершаете одинаковые действия, с одинаковыми объектами, обращаясь на одинаковые URL, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.

Ответ написан

Ошибка 404 — Not Found

Похоже, что кто-то взял эту страницу и не вернул назад. Испытайте удачу на новой. Список чуть ниже.

It looks like somebody took this page away and did not put it back.

  • IT PC
    • Система компьютерной вёрстки LaTeX
      • Самоучитель LaTeX
      • Символы LaTeX
      • LaTeX → HTML
      • WinEdt
      • MikTex
      • Видеоуроки LaTeX
      • Титульный лист LaTeX
    • Операционные системы Линукс
      • Debian FAQ
      • Debian
      • Дневник — первый опыт с Debian
      • Memory stick в Debian
      • Configure Make Install
      • Настройка сети в Linux
      • Системная переменная PATH Linux
      • Virtualbox
      • Bash
        • Bash Scripting
      • Ubuntu
      • CentOS
    • DEVOPS
      • AWS
      • Git
      • Docker
      • Virtulabox
        • Уставновка виртуальной Windows 7 с помощью Virtulabox в Debian
    • Операционная система OpenBSD
    • Программы, за которые не нужно платить
    • Программирование
      • Язык программирования Си
      • Язык программирования Си++
      • Java Script
      • Язык программирования Python
        • Python: сложности, нюансы, детали.
        • PIP
      • Язык программирования Ruby
      • Язык программирования PHP
        • Как отобразить время различных часовых поясов PHP
        • Как вставить переменную в ссылку PHP
        • json_decode PHP
        • Как определить ширину экрана PHP
        • Premature end of chunk coded message body: closing chunk expected
    • Web
      • Язык разметки HTML
      • CMS Joomla
      • Браузер Mozilla Firefox
      • Переадресация внутри сайта
    • IT Helpdesk
      • Заметки о BAT файлах
      • Доступ по RDP через SSH туннель
      • Grep
      • Sed
      • Awk
      • Заметки о системном администрировании
      • Режим разработчика в Windows 10
      • Использование Bash в Windows 10
      • Запись установочного образа на флешку с помощью UltraISO
      • Firewall Windows
    • Microsoft Office
      • Microsoft Excel
        • Цветной выпадающий список
        • Всё пропало
      • Microsoft Word
    • Как создать репозиторий с помощью TortoiseSVN
    • Тестирование ПО
      • Jira
      • Учебник
      • Тестирвоание API
      • SOAP UI
      • Clumsy 0. 2
      • Postman
      • Тестирование с Python
      • Cherry Picking
  • Образование
    • Физика
      • Физика 6 класс
      • Физика 7 класс
      • Физика 8 класс
      • Физика 9 класс
      • Физика ГИА
      • Физика 10 класс
      • Физика 11 класс
      • Физика ЕГЭ
      • Прикладная оптика
      • Микроэлектроника
      • Оптоэлектроника
      • Оптическая спектроскопия
      • Антенны
    • Математика
    • Ядерная физика
      • Заметки о ядерной физике
        • Ядерные уровни
        • Эффективное поперечное сечение
        • Деление ядер
        • Распределение энергии деления 235U тепловыми нейтронами между продуктами.
        • Классификация частиц
        • Видеоматериалы
      • Кафедра ядерной физики СПбГУ
        • Конспекты и прочее
        • Основные свойства атомных ядер
        • Ядерные силы
        • Электронные методы
        • Вторичное квантование
        • Теория групп
        • Резонансное рассеяние гамма-лучей
        • Ядерные реакции
        • Кварковая структура адронов
        • Основы дозиметрии
        • Экзотические ядра
        • Внутренняя конверсия
        • Слабые и электромагнитные процессы
        • Прямые ядерные реакции
        • Квантовая хромодинамика
        • Нейтронные резонансы и нейтронная оптика
        • Тяжёлые ионы
    • Атомная энергетика
      • Список принятых в ядерной энергетике сокращений
      • ВВЭР
    • Физический факультет СПбГУ
      • Численные методы
      • Болонский процесс
      • Жизнь студентов — покупательная способность стипендии
      • ПУНК глазами немцев
      • Впечатления Максима Николаевича
      • Максим Николаевич о Физ-факе
    • Теорвер
      • Задачи по теорверу
    • Английския язык
      • Вводные предложения в английском языке
    • Литература
      • Эрих Мария Ремарк. В каком порядке читать
      • Эрих Мария Ремарк. Фильмы
      • Эрих Мария Ремарк. Аудиокниги
      • Кормак МакКарти
      • Анджей Сапковский. Ведьмак
      • Бокононизм
  • Физкультура, спорт, здоровье
    • Баскетбол
      • Баскетбольный клуб Спартак Санкт-Петербург
        • Видео
          • 2013 Осень
          • 2013 Весна
          • 2012 Осень
          • 2012 Весна
          • 2011 Осень
          • 2011 Весна
          • 2010 Весна
          • 2009 Осень
          • 2009 Весна
          • 2008 Осень
          • 2000 — 2005
          • 90-е
        • Bisons — Спартак (6 ноября 2013)
      • Физическая подготовка
      • Техника
    • Здоровый образ жизни
  • Разное
    • Инновационный центр СПбГУ
    • Поликлиника в ПГТ им. Морозова
    • Навальный и Носик считают деньги
    • Карта сайта
    • RFID
      • RFID Основы
      • RFID тэги
      • RFID Компании
      • Online инструменты
      • RFID словарь
  • Реклама
  • Блог
    • Varis
  • Другие проекты
    • HeiHei.ru
    • TopBicycle.ru
  • Mузыка
    • Музыка
    • Maruv
    • Холстинин
    • Ежемесячные
    • Лук, лучок
    • Валентин Дядька
    • Бутер Бродский
  • Поиск по сайту
  • aofeed — Telegram канал чтобы следить за выходом новых статей
  • aofeedchat — задать вопрос в Телеграм-группе
Контакты и сотрудничество:
Рекомендую наш хостинг beget. ru
Пишите на [email protected] если Вы:
1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык.
2. Хотите разместить на сайте рекламу, подходящуюю по тематике.
3. Реклама на моём сайте имеет максимальный уровень цензуры. Если Вы увидели рекламный блок недопустимый для просмотра детьми школьного возраста, вызывающий шок или вводящий в заблуждение — пожалуйста свяжитесь с нами по электронной почте
4. Нашли на сайте ошибку, неточности, баг и т.д. … …….
5. Статьи можно расшарить в соцсетях, нажав на иконку сети:

Тестирование PUT-запросов

Автор: Кристин Джеквони (Kristin Jackvony)

Оригинал статьи

Перевод: Ольга Алифанова.

Сегодня мы обсудим тестирование PUT-запросов. В целом они очень похожи на POST-запросы – основное отличие в том, что POST создает новую запись, а PUT заменяют существующую.

Вернемся в Swagger Pet Store, чтобы разобраться, как создавать PUT-запрос. Кликните по запросу PUT /pet, чтобы открыть его:


Можно отметить, что адрес и тело запроса совпадают с запросом POST, и единственная разница тут в HTTP-глаголе: PUT, а не POST. Чтобы увидеть, как работает PUT-запрос, давайте создадим POST-запрос со следующими значениями:

{
  "id": 1,
  "category": {
    "id": 1,
    "name": "Cat"
  },
  "name": "Grumpy Cat",
  "photoUrls": [
    "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg"
  ],
  "tags": [
    {
      "id": 1,
      "name": "Mixed breed"
    }
  ],
  "status": "available"
}

Теперь сделайте GET-запрос, чтобы убедиться, что питомец правильно добавился. А теперь сделаем PUT-запрос с вот такими значениями:

{
  "id": 1,
  "category": {
    "id": 2,
    "name": "Dog"
  },
  "name": "Droopy Dog",
  "photoUrls": [
    "https://upload.wikimedia.org/wikipedia/en/thumb/f/fd/Droopy_dog.png/150px-Droopy_dog.png"
  ],
  "tags": [
    {
      "id": 2,
      "name": "Beagle"
    }
  ],
  "status": "pending"
}

Заметьте, что все значения в теле запроса изменены, кроме id питомца. После отправки запроса выполните GET, чтобы убедиться, что значения изменились.

PUT-запрос всегда заменяет ВСЕ значения во всей записи, и это значит, что если каких-то значений не хватает – они будут удалены. К примеру, если мы делаем PUT-запрос для того же ID, включающий только имя и адрес фотографии, то это все, что сохранит сервер. Тэги, статус, и все остальное удалится.

Чтобы разобраться в тестировании PUT-запросов, я забуду на минутку про Swagger Pet Store и приведу другой пример. Предположим, у нас есть приложение, хранящее список сотрудников. Оно пишет данные в таблицу с такими значениями:


PUT-запрос для обновления записи в этой таблице будет выглядеть так:

{
  "firstName": "Amy",
  "lastName": "Miller"
}

URL этого запроса будет таким: app/employee/1. В этом приложении id сотрудника передается через URL, а не в теле запроса (это довольно распространенная практика).

Начнем мы тестирование этого воображаемого приложения со «счастливого пути»: если мы отправим этот запрос, изменится ли имя сотрудника номер 1 на Эми Миллер с Фреда Смита? Это можно проверить, напрямую запросив базу данных, или использовав GET-запрос.

Затем мы посмотрим, что будет, если отправить PUT-запрос для записи, которой не существует. Представьте аналогичный запрос, где вместо URL app/employee/1 используется URL app/employee/3. Как можно увидеть в табличке, записи 3 не существует. Запрос должен вернуть ошибку – например, 404 Not Found. Можно также передать бессмысленные id (буквы, слова, символы), и вообще их не передать. Все эти запросы должны возвращать соответствующие ошибки.

Теперь давайте обратимся к телу нашего запроса. Представьте, что firstName и lastName – необходимые для запроса поля. Мы должны получить сообщение об ошибке, если передали пустое тело, или только имя, или только фамилию. В сценарии, где полей гораздо больше, чем у нас, стоит проверить множество различных комбинаций, где отсутствуют различные обязательные и необязательные поля.

Как я уже упоминала, PUT-запросы должны заменять ВСЕ значения в записи: она как будто бы полностью удалялась и была заменена на абсолютно новую. Представим сценарий, в котором firstName – необязательное поле, а запись 1 выглядит как Amy Miller. Если мы проведем тест с отправкой только lastName («Brown»), у записи 1 должна появиться пустота в поле firstName, а lastName должно измениться на Brown.

Также можно посмотреть, что будет, если попробовать передать запрос с полями, которых вообще нет в таблице! К примеру, вот так:

{
  "firstName": "Amy",
  "middleName": "Jo"
  "lastName": "Miller"
}

Убедитесь, что или это поле будет проигнорировано, или вы получите сообщение об ошибке.

Теперь мы можем перейти к тестированию отдельных полей. Какие значения в них разрешены? Есть ли ограничения по количеству символов? Стоит протестировать каждое поле, чтобы убедиться, что вы получаете соответствующее сообщение об ошибке при нарушении ограничений, а также при передаче недопустимых символов или значений. Можно также попробовать отправить значения, которые можно использовать для внедрения сценариев или SQL-инъекций: они должны или отвергаться, или очищаться, чтобы вредоносная атака не сработала.

И, наконец, можно поиграть с HTTP-глаголом и запросом в целом. Что будет, если поменять PUT на POST? В нашем гипотетическом приложении POST-запрос с URL app/employee/1 вернет ошибку 409, потому что запись с таким id уже существует. Можно также посмотреть, что произойдет, если удалить или поменять необходимые заголовки в запросе.

Надеюсь, что эта статья дала вам представление о поведении PUT-запросов и способов их протестировать.

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Предыдущие статьи на эту тему

Введение в REST-запросы и тестирование GET-запросов

Тестирование POST-запросов

Обсудить статью в форуме

Когда использовать HTTP PUT и HTTP POST

Протокол HTTP определяет два метода обновления ресурса — PUT и ПОЧТ . И PUT , и POST используются для изменения ресурса, и эта семантическая сходство может сбить с толку разработчиков API. Эта путаница привела большинство разработчиков к используйте POST для любого действия, которое может изменить состояние ресурса, игнорируя ПОСТАВИТЬ целиком.

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

ПУТ

Давайте перейдем прямо к HTTP/1.1 RFC для определения PUT.

Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Запрос-URI. Если Request-URI относится к уже существующему ресурсу, закрытое существо СЛЕДУЕТ рассматривать как модифицированную версию того, на исходном сервере. Если Request-URI не указывает на существующий ресурс … исходный сервер может создать ресурс с этим URI.

Спецификация PUT требует, чтобы вы уже знали URL-адрес ресурса, который вы хотите создать или обновить. При создании, если клиент выбирает идентификатор для resource запрос PUT создаст новый ресурс по указанному URL-адресу.

 ПОЛОЖИТЬ /пользователь/1234567890 HTTP/1.1
Хост: http://sookocheff.com
{
"name": "Кевин Сукочефф",
"веб-сайт": "http://kevinsookocheff. com"
}

Сервер может ответить кодом состояния 201 Created и новым ресурсом. расположение.

 HTTP/1.1 201 Создано
Расположение: /пользователь/1234567890

Кроме того, если вы знаете, что ресурс для URL-адреса уже существует, вы можете запрос PUT к этому URL-адресу, чтобы заменить состояние этого ресурса на сервере. Этот пример обновляет веб-сайт пользователя.

 ПОЛОЖИТЬ /пользователь/1234567890 HTTP/1.1
Хост: http://sookocheff.com
{
"name": "Кевин Сукочефф",
"веб-сайт": "http://sookocheff.com"
}

Обычно метод HTTP PUT заменяет ресурс по текущему URL-адресу на ресурс, содержащийся в запросе. PUT используется как для создания, так и для обновления состояние ресурса на сервере.

ПОЧТ

Давайте вернемся к HTTP/1.1 RFC для определения POST.

Метод POST используется для запроса того, чтобы исходный сервер принял объект вложенный в запрос как новый подчиненный ресурс, идентифицированный Request-URI … Опубликованный объект подчинен этому URI таким же образом что файл подчинен каталогу, содержащему его, новостная статья подчинена группе новостей, в которой она опубликована, или запись подчинена в базу данных.

На практике POST используется для добавления ресурса к существующему коллекция. В следующем примере вы не знаете фактический URL-адрес ресурс — сервер определяет место, где он хранится под пользовательская коллекция .

 POST/пользователь HTTP/1.1
Хост: http://sookocheff.com
{
    "имя": "Брайан Ларсон",
    "веб-сайт": "http://www.bryanlarson.ca"
}

Сервер может ответить кодом состояния 201 Created и новым ресурсом. расположение.

 HTTP/1.1 201 Создано
Расположение: /пользователь/636363

Последующие обновления для этого пользователя будут выполняться с помощью запроса PUT к конкретный URL для пользователя — /user/636363 .

Книга RESTful Web API классифицировать это поведение POST-to-append и является обычно рекомендуемым способом обрабатывать запрос POST в контексте определенного ресурса.

Собираем вместе

HTTP/1.1 RFC предлагает некоторые рекомендации по различению POST и ПОМЕЩАТЬ.

Принципиальное различие между запросами POST и PUT отражено в другое значение Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать вложенный объект… Напротив, URI в запрос PUT идентифицирует объект, заключенный в запросе.

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

гипермедиа отдыхать API почта поставить

См.
также
  • Ложная дихотомия между проектированием и разработкой API в первую очередь кодом
  • Собор, базар и рынок API
  • Объединение RESTful HTTP с асинхронными и управляемыми событиями службами
  • Чрезмерно амбициозные API-шлюзы
  • Загрузка больших полезных данных через шлюз API

HTTP/1.1: определения методов

HTTP/1.1: определения методов
часть протокола передачи гипертекста — HTTP/1.1
RFC 2616 Филдинг и др.

Набор общих методов для HTTP/1.1 определен ниже. Несмотря на то что этот набор можно расширить, нельзя предполагать, что дополнительные методы используют одну и ту же семантику для отдельно расширенных клиентов и серверов.

Поле заголовка запроса хоста (раздел 14. 23) ДОЛЖНО сопровождать все Запросы HTTP/1.1.

9.1 Безопасные и идемпотентные методы

9.1.1 Безопасные методы

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

В частности, было установлено соглашение о том, что GET и Методы HEAD НЕ ДОЛЖНЫ иметь значение выполнения действия кроме поиска. Эти методы следует считать «безопасными». Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT. и УДАЛИТЬ, особым образом, чтобы пользователь знал о тот факт, что запрашивается возможно небезопасное действие.

Естественно, невозможно гарантировать, что сервер не генерировать побочные эффекты в результате выполнения GET-запроса; в на самом деле, некоторые динамические ресурсы считают это особенностью. Важный отличие здесь в том, что пользователь не запрашивал побочные эффекты, поэтому не может нести за них ответственность.

9.1.2 Идемпотентные методы

Методы также могут обладать свойством «идемпотентности» в том, что (кроме из-за ошибок или проблем с истечением срока действия) побочные эффекты N > 0 идентичны запросы такие же, как и для одного запроса. Методы GET, HEAD, PUT и DELETE разделяют это свойство. Кроме того, методы OPTIONS и TRACE НЕ ДОЛЖЕН иметь побочных эффектов, поэтому они по своей сути идемпотентны.

Однако возможно, что последовательность из нескольких запросов не идемпотент, даже если все методы, выполняемые в этой последовательности, идемпотент. (Последовательность является идемпотентной, если одно выполнение вся последовательность всегда дает результат, который не изменяется повторного выполнения всей или части этой последовательности.) Например, последовательность неидемпотентна, если ее результат зависит от значения, которое позже изменены в той же последовательности.

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

9.2 ОПЦИИ

Метод OPTIONS представляет собой запрос информации о варианты связи, доступные в цепочке запросов/ответов определяется Request-URI. Этот метод позволяет клиенту определить варианты и/или требования, связанные с ресурсом, или возможности сервера, не подразумевая действие ресурса или инициирование поиска ресурсов.

Ответы на этот метод не кэшируются.

Если запрос OPTIONS включает тело объекта (как указано наличие Content-Length или Transfer-Encoding), то тип носителя ДОЛЖЕН указываться полем Content-Type. Хотя это спецификация не определяет какое-либо использование такого кузова в будущем расширения для HTTP могут использовать тело OPTIONS, чтобы сделать более подробными запросы на сервере. Сервер, который не поддерживает такой расширение МОЖЕТ отбросить тело запроса.

Если Request-URI представляет собой звездочку («*»), запрос OPTIONS предназначен для применения к серверу в целом, а не к конкретному ресурс. Поскольку параметры связи сервера обычно зависят от ресурс, запрос «*» полезен только как «ping» или «no-op» тип метода; он ничего не делает, кроме как позволяет клиенту протестировать возможности сервера. Например, это можно использовать для проверки прокси для соответствия HTTP/1.1 (или его отсутствия).

Если Request-URI не является звездочкой, применяется запрос OPTIONS. только к тем вариантам, которые доступны при общении с этим ресурс.

Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают дополнительные функции, реализованные сервером и применимые к этому ресурс (например, Разрешить), возможно, включая расширения, не определенные эта спецификация. Тело ответа, если таковое имеется, СЛЕДУЕТ также включать информация о возможностях связи. Формат для такого

body не определяется этой спецификацией, но может быть определено будущие расширения HTTP. Согласование содержимого МОЖЕТ использоваться для выбора соответствующий формат ответа. Если тело ответа не включено, ответ ДОЛЖЕН включать поле Content-Length со значением поля «0».

Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для конкретный прокси в цепочке запросов. Когда прокси получает OPTIONS запрос на absoluteURI, для которого разрешена переадресация запроса, прокси-сервер ДОЛЖЕН проверять наличие поля Max-Forwards. Если Макс-Форвардс значение поля равно нулю («0»), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение; вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи. Если значение поля Max-Forwards является целым числом больше нуля, прокси ДОЛЖЕН уменьшать значение поля при пересылке запроса. Если поле Max-Forwards отсутствует в запросе, то перенаправленный запрос НЕ ДОЛЖЕН включать поле Max-Forwards.

9.3 ПОЛУЧИТЬ

Метод GET означает получение любой информации (в виде сущность) идентифицируется Request-URI. Если Request-URI ссылается к процессу производства данных именно произведенные данные должны быть возвращается как сущность в ответе, а не как исходный текст процесса, если только этот текст не является результатом процесса.

Семантика метода GET меняется на «условный GET», если сообщение запроса включает в себя If-Modified-Since, If-Unmodified-Since, Поле заголовка If-Match, If-None-Match или If-Range. Условный GET метод требует, чтобы сущность передавалась только под обстоятельства, описываемые условным полем(ями) заголовка. условный метод GET предназначен для сокращения ненужных сетевых запросов. использования, позволяя обновлять кэшированные объекты без необходимости несколько запросов или передача данных, уже имеющихся у клиента.

Семантика метода GET меняется на «частичный GET», если сообщение запроса включает в себя поле заголовка Range. Частичные GET-запросы что только часть объекта будет передана, как описано в разделе 14.35. Частичный метод GET предназначен для сокращения ненужных использования сети, позволяя частично извлеченным объектам быть завершена без передачи данных, уже имеющихся у клиента.

Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует требования к кэшированию HTTP, описанные в разделе 13.

См. раздел 15.1.3 по соображениям безопасности при использовании для форм.

9.4 ГОЛОВКА

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН вернуть тело сообщения в ответ. Метаинформация содержала в заголовках HTTP в ответ на запрос HEAD ДОЛЖЕН быть идентичным к информации, отправленной в ответ на запрос GET. Этот метод может использоваться для получения метаинформации об объекте, подразумеваемом запрос без передачи самого тела сущности. Этот метод часто используется для проверки гипертекстовых ссылок на достоверность, доступность, и недавняя модификация.

Ответ на запрос HEAD МОЖЕТ кэшироваться в том смысле, что информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления ранее кэшированный объект из этого ресурса. Если новые значения поля указать, что кэшированный объект отличается от текущего объекта (как будет указано изменением Content-Length, Content-MD5, ETag или Last-Modified), то кэш ДОЛЖЕН обрабатывать запись кэша как несвежий.

9.5 ПОСТ

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

 - Аннотация существующих ресурсов;
 
 - Публикация сообщения на доске объявлений, в группе новостей, в списке рассылки,
        или аналогичная группа статей;
 
 - Предоставление блока данных, например, в результате отправки
        форма для процесса обработки данных;
 
 - Расширение базы данных с помощью операции добавления.

Фактическая функция, выполняемая методом POST, определяется server и обычно зависит от Request-URI. Размещенный объект является подчиненным этому URI так же, как файл является подчиненным к каталогу, содержащему его, новостная статья подчинена группа новостей, в которую она отправлена, или запись подчинена база данных.

Действие, выполняемое методом POST, может не привести к ресурс, который можно идентифицировать по URI. В этом случае либо 200 (ОК) или 204 (Нет содержимого) — соответствующий статус ответа, в зависимости от того, включает ли ответ объект, который описывает результат.

Если ресурс был создан на исходном сервере, ответ ДОЛЖЕН иметь значение 201 (Создано) и содержать сущность, описывающую статус запроса и относится к новому ресурсу, а местоположение заголовок (см. раздел 14.30).

Ответы на этот метод не кэшируются, если только ответ включает соответствующие поля заголовка Cache-Control или Expires. Однако, ответ 303 (см. Другое) может использоваться для направления пользовательского агента к получить кешируемый ресурс.

Запросы POST ДОЛЖНЫ соответствовать требованиям к передаче сообщений, изложенным в разделе 8.2.

См. раздел 15.1.3 по соображениям безопасности.

9.6 ПУТ

Метод PUT запрашивает, чтобы вложенный объект был сохранен в предоставленный Request-URI. Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированная версия той, что находится на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользователем агент, исходный сервер может создать ресурс с этим URI. Если создается новый ресурс, исходный сервер ДОЛЖЕН информировать пользовательский агент через ответ 201 (Создано). Если существующий ресурс изменен, ДОЛЖНЫ быть отправлены коды ответов 200 (ОК) или 204 (Нет контента). чтобы указать на успешное выполнение запроса. Если ресурс не может быть создан или изменен с помощью Request-URI, соответствующий СЛЕДУЕТ давать ответ об ошибке, отражающий природу ошибки. проблема. Получатель объекта НЕ ДОЛЖЕН игнорировать любой Контент-* (например, Content-Range) заголовки, которые он не понимает или не реализует и ДОЛЖЕН возвращать ответ 501 (не реализовано) в таких случаях.

Если запрос проходит через кеш и Request-URI идентифицирует один или несколько кэшированных объектов, эти записи ДОЛЖНЫ быть рассматривается как устаревший. Ответы на этот метод не кэшируются.

Фундаментальное различие между запросами POST и PUT заключается в следующем. отражается в различном значении Request-URI. URI в Запрос POST идентифицирует ресурс, который будет обрабатывать вложенный организация. Этот ресурс может быть процессом приема данных, шлюзом к какой-то другой протокол или отдельный объект, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом — пользовательский агент знает, какой URI предназначен, и сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу. Если сервер желает, чтобы запрос был применен к другому URI,

он ДОЛЖЕН отправить ответ 301 (перемещен навсегда); пользовательский агент МОЖЕТ затем принять собственное решение относительно того, следует ли перенаправлять запрос.

Один ресурс МОЖЕТ быть идентифицирован многими различными URI. За например, статья может иметь URI для идентификации «текущего версия», которая отделена от URI, идентифицирующего каждую конкретную версия. В этом случае запрос PUT на общий URI может привести к несколько других URI определяются исходным сервером.

HTTP/1.1 не определяет, как метод PUT влияет на состояние исходный сервер.

Запросы PUT ДОЛЖНЫ соответствовать требованиям к передаче сообщений, изложенным в разделе 8. 2.

Если иное не указано для конкретного заголовка сущности, заголовки объектов в запросе PUT ДОЛЖНЫ применяться к ресурсу созданный или измененный PUT.

9.7 УДАЛИТЬ

Метод DELETE запрашивает, чтобы исходный сервер удалил ресурс. определяется Request-URI. Этот метод МОЖЕТ быть переопределен человеком вмешательство (или другие средства) на исходном сервере. клиент не может гарантировать, что операция была выполнена, даже если код состояния, возвращенный исходным сервером, указывает, что действие был успешно завершен. Однако сервер НЕ ДОЛЖЕН указывают на успех, если только в момент ответа намеревается удалить ресурс или переместить его в недоступное расположение.

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответ включает в себя объект, описывающий статус, 202 (Принято), если действие не было еще не было выполнено, или 204 (Нет контента), если действие было выполнено. но ответ не включает сущность.

Если запрос проходит через кеш и Request-URI идентифицирует один или несколько кэшированных объектов, эти записи ДОЛЖНЫ быть рассматривается как устаревший. Ответы на этот метод не кэшируются.

9.8 ТРАССА

Метод TRACE используется для вызова удаленного цикла прикладного уровня. обратная сторона сообщения запроса. Конечный получатель запроса СЛЕДУЕТ отражать сообщение, полученное обратно клиенту, как сущность-тело ответа 200 (ОК). Конечным получателем является либо

исходный сервер или первый прокси или шлюз, получивший Max-Forwards значение нуля (0) в запросе (см. раздел 14.31). TRACE-запрос НЕ ДОЛЖЕН включать сущность.

TRACE позволяет клиенту видеть, что принимается на другом конец цепочки запросов и использовать эти данные для тестирования или диагностики Информация. Значение поля заголовка Via (раздел 14.45) равно особый интерес, так как он действует как трассировка цепочки запросов. Использование поля заголовка Max-Forwards позволяет клиенту ограничить длина цепочки запросов, которая полезна для тестирования цепочки прокси пересылают сообщения в бесконечном цикле.

Если запрос действителен, ответ ДОЛЖЕН содержать все сообщение запроса в теле сущности с типом содержимого «сообщение/http». Ответы на этот метод НЕ ДОЛЖНЫ кэшироваться.

9.9 ПОДКЛЮЧЕНИЕ

Эта спецификация резервирует имя метода CONNECT для использования с прокси, который может динамически переключаться на туннель (например, SSL туннелирование [44]).

PUT против POST — разница между ними

АвторLawrence Williams

Часы

Обновлено

Ключевые различия между PUT и POST
  • Метод PUT вызывается, когда вам нужно изменить один ресурс, а метод POST вызывается, когда вам нужно добавить дочерний ресурс.
  • Ответы метода PUT можно кэшировать, но нельзя кэшировать ответы метода POST.
  • Вы можете использовать запрос UPDATE в PUT, тогда как вы можете использовать запрос создания в POST.
  • В методе PUT клиент решает, какой ресурс URI должен иметь, а в методе POST сервер решает, какой ресурс URI должен иметь.
  • PUT работает как конкретный, а POST работает как абстрактный.
  • Если вы отправляете один и тот же запрос PUT несколько раз, результат останется тем же, но если вы отправляете один и тот же запрос POST несколько раз, вы получите разные результаты.
  • Метод PUT является идемпотентным, тогда как метод POST не является идемпотентным.
ПОСТАВИТЬ против ПОЧТА

Что такое метод PUT?

Метод PUT используется для обновления ресурсов, доступных на сервере. Как правило, он заменяет все, что существует по целевому URL-адресу, чем-то другим. Вы можете использовать его, чтобы создать новый ресурс или перезаписать существующий. PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным запрошенным URI (унифицированным идентификатором ресурса).

Что такое метод POST?

POST — это метод, поддерживаемый HTTP, а

показывает, что веб-сервер принимает данные, включенные в тело запрошенного сообщения. POST часто используется World Wide Web для отправки сгенерированных пользователем данных на веб-сервер или при загрузке файла.

Различия между PUT и POST в REST API

Вот важное различие между методом PUT и POST:

PUT ПОСТ
Этот метод является идемпотентным. Этот метод не является идемпотентным.
Метод PUT вызывается, когда вам нужно изменить один ресурс, который уже является частью коллекции ресурсов. Метод POST вызывается, когда вам нужно добавить дочерний ресурс в коллекцию ресурсов.
RFC-2616 показывает, что метод PUT отправляет запрос на вложенный объект, хранящийся в предоставленном URI запроса. Этот метод запрашивает у сервера принять сущность, заключенную в запросе.
Синтаксис метода PUT: PUT /questions/{id вопроса} Синтаксис метода POST: POST/questions
Ответ метода PUT можно кэшировать. Вы не можете кэшировать ответы метода PUT.
PUT /vi/juice/orders/1234 указывает, что вы обновляете ресурс, который идентифицируется как «1234». POST /vi/juice/orders указывает, что вы создаете новый ресурс и возвращаете идентификатор для описания ресурса.
Если вы отправляете один и тот же запрос несколько раз, результат останется прежним. Если вы отправляете один и тот же запрос POST более одного раза, вы получите разные результаты.
PUT работает как специфичный. POST работает как реферат.
Мы используем запрос UPDATE в PUT. Мы используем запрос на создание в POST.
В методе PUT клиент решает, какой ресурс URI должен иметь. В методе POST сервер решает, какой ресурс URI должен иметь.

Пример PUT

Вот пример метода PUT для веб-сервера:

HTTP PUT http://www.google.com/users/234

HTTP PUT http://www.google.com/ users/234/accounts/567

Запрос 

 PUT /new.html HTTP/1.1
Хост: example.com
Тип контента: текст/html
Длина содержимого: 20

Новый файл

Ответы

Если целевой ресурс имеет текущее представление и изменен состоянием вложенного представления, то сервер должен отправить два ответа. Первый код ответа — 200 (ОК), а второй код ответа — 204 (Нет содержимого).

Если целевой ресурс не имеет никакого представления, сервер должен сообщить об этом пользователю, отправив ответ с кодом 201 (Создано).

 HTTP/1.1 201 Создано
Content-Location: /new.html

Пример POST

Вот пример метода POST:

HTTP POST http://www.google.com/users

HTTP POST http://www. google. com/users/234/accounts

Форма, использующая тип содержимого application/x-www-form-urlencoded по умолчанию:

 POST /test HTTP/1.1
Хост: abc.example
Content-Type: application/x-www-form-urlencoded
Длина содержимого: 40
поле1=значение1&поле2=значение2

Тестирование API с запросами PUT

Вот шаги для тестирования API с запросами PUT:

Тестирование API с запросами PUT

Шаг 1) Обновите ресурсы с помощью запроса PUT.

Шаг 2) Используйте метод GET для ресурса. Если запрос PUT выполнен успешно, вы получите новые данные. Этот метод завершится ошибкой, если предоставленные данные в запросе недействительны. Поэтому ничего обновлять не будет.

Тестирование API с запросами POST

Вот шаги для тестирования API с запросами POST:

Тестирование API с помощью POST-запросов

Шаг 1) Создайте ресурс с помощью POST-запроса и убедитесь, что он возвращает код состояния 200.

Шаг 2) Сделайте запрос GET для этого ресурса и сохраните данные в правильном формате.

Шаг 3) Вы должны добавить тесты, которые гарантируют, что POST-запросы не будут содержать неверные данные.

Преимущества метода PUT

Вот преимущества и преимущества использования метода PUT:

  • Это поможет вам сохранить предоставленный объект под предоставленным URI
  • Если предоставленный объект уже существует, вы можете выполнить операцию обновления или создать его с этим URI.
  • Вы можете создавать ресурс сколько угодно раз.
  • Создать ресурс с помощью метода PUT очень просто.
  • Вам не нужно проверять, нажал ли пользователь кнопку отправки несколько раз или нет.
  • Может идентифицировать сущность, вложенную в запрос.

Преимущества метода POST

Вот преимущества и преимущества использования метода POST:

  • Этот метод помогает определить URI ресурса.

    No related posts.