Разница между PUT и POST
Насколько я понимаю все это, то, если сравнить PUT и POST операциями в MySQL, то POST — это INSERT, а PUT — UPDATE or INSERT
by KES
Расмотрим на примере форума. В нём есть темы и сообщения. Мы делаем запросы в тему hello
POST /topic/hello?message = Здесь POST /topic/hello?message = был POST /topic/hello?message = Вася
Первый запрос создаст (INSERT) тему hello с сообщением «Здесь», остальные два запроса тоже создадут (INSERT) новые сообщения в теме. В результате у нас получится, что тема hello содержит: Здесь был Вася.
PUT /topic/hello?message = Здесь PUT /topic/hello?message = был PUT /topic/hello?message = Вася
Первый запрос создаст (INSERT) тему hello с сообщением «Здесь», остальные два запроса обновят (UPDATE) сообщение в теме. В результате у нас получится, что тема hello содержит: Вася.
Идемпотентность PUT здесь проявляется в том, что 
Касательно ссылок — карта сайта будет оставаться неизменной. Будет обновляться лишь содержимое тем.
или: каждый запрос POST /article/hello будет создавать новую главу в статье hello. Первый запрос создаст саму статью.
каждый запрос PUT /article/hello будет обновлять ЕДИНСТВЕННУЮ главу в статье hello. Первый запрос создаст саму статью.
Вот, что нам должен возвращать GET, если мы делали POST
GET /topic/hello 201 Здесь был Вася
В этом случае у нас также будут доступны и эти URI
GET /topic/hello/1 201 Здесь GET /topic/hello/2 201 был GET /topic/hello/3 201 Вася
Вот, что нам должен вернуть GET, если мы делали PUT
GET /topic/hello 201 Вася
В этом случае у нас будет доступна только одна URI
GET /topic/hello/1 201 Вася GET /topic/hello/2 404 GET /topic/hello/3 404
EXAMPLE #2 Пример с пользователями.
POST /user/eugen?age=7 POST /user/eugen?age=10 POST /user/eugen?age=5
Создаст 3 пользователя с именем eugen и возрастом 7, 10, 5, соответственно.
PUT /user/eugen?age=7 PUT /user/eugen?age=10 PUT /user/eugen?age=5
Будет создан только один пользователь с именем eugen с возрастом 5
Другими словами: PUT обязан обновлять запись, если данные уже есть
Отсюда и Ваш пример String userId = this.request["USER_ID"]; с сохранением значения в переменной. Сколько раз вы бы не ложили (PUT) значения в переменную — переменная всегда будет одна.
Отсюда родился EXAMPLE #3
Не знаю на сколько эта аналогия верна, но думаю это утверждение будет верно:
POST: push $variable, value; -- в итоге массив значений PUT: $variable = value; -- в итоге одно значение
в случае POST, вред, который может возникнут, это переполнится память сервера. В случае PUT — никакого вреда нет, только такты забираются 😉
Кстати, вот нашел хороший ресурс, по поводу безопасности и идемпотентности http://restcookbook.com/HTTP%20Methods/idempotency/
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 — обновить существующую записьОтвет написан
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(.: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, с одинаковыми наборами параметров. Поведение всех систем предсказуемое, все подвластно единой концепции.
Ответ написан
В чем разница между POST и PUT HTTP REQUEST?
На самом деле нет никакой разницы, кроме названия. На самом деле есть основное различие между GET и другими. С помощью метода «GET»-Request вы отправляете данные в строке url-адреса, которые сначала разделяются знаком вопроса, а затем знаком &.
Но с методом «POST»-запроса вы не можете передавать данные через URL-адрес, но вы должны передавать данные как объект в так называемом «теле» запроса. Затем на стороне сервера вы должны прочитать тело полученного контента, чтобы получить отправленные данные. Но с другой стороны нет возможности отправить содержимое в теле, когда вы отправляете запрос «GET».
Утверждение, что «GET» предназначено только для получения данных, а «POST» — для отправки данных, абсолютно неверно. Никто не может помешать вам создавать новый контент, удалять существующий контент, редактировать существующий контент или делать что-либо еще в бэкэнде на основе данных, отправленных запросом «GET» или запросом «POST». И никто не может помешать вам запрограммировать бэкенд таким образом, чтобы с помощью «POST»-запроса клиент запросил некоторые данные.
С запросом, независимо от того, какой метод вы используете, вы вызываете URL-адрес и отправляете или не отправляете некоторые данные, чтобы указать, какую информацию вы хотите передать на сервер для обработки вашего запроса, а затем клиент получает ответ с сервера.
Данные могут содержать все, что вы хотите отправить, бэкенду разрешено делать с данными все, что он хочет, а ответ может содержать любую информацию, которую вы хотите поместить туда.
Есть только эти два ОСНОВНЫХ МЕТОДА. ПОЛУЧИТЬ и ОТПРАВИТЬ. Но их отличает структура, а не то, что вы кодируете в бэкэнде. В бэкенде вы можете кодировать все, что хотите, с полученными данными. Но при «POST»-запросе вы должны отправлять/получать данные в теле, а не в url-адресной строке, а при «GET»-запросе вы должны отправлять/получать данные в url-адресной строке, а не в тело. Вот и все.
Все остальные методы, такие как «PUT», «DELETE» и т. д., имеют ту же структуру, что и «POST».
Метод POST в основном используется, если вы хотите несколько скрыть содержимое, потому что все, что вы пишете в строке URL-адреса, будет сохранено в кеше, а метод GET аналогичен написанию строки URL-адреса с помощью данные. Поэтому, если вы хотите отправить конфиденциальные данные, которые не всегда являются именем пользователя и паролем, но, например, некоторые идентификаторы или хэши, которые вы не хотите отображать в строке URL-адреса, вам следует использовать метод POST .
Также длина строки URL-адреса ограничена 1024 символами, тогда как метод «POST» не ограничен. Поэтому, если у вас есть больший объем данных, вы не сможете отправить его с помощью GET-запроса, но вам нужно будет использовать POST-запрос. Так что это еще один плюс для POST-запроса.
Но работать с GET-запросом намного проще, когда нет сложного текста для отправки. В противном случае, и это еще один плюс для метода POST, заключается в том, что с методом GET вам необходимо кодировать текст по URL-адресу, чтобы иметь возможность отправлять некоторые символы в тексте или даже пробелы. Но с методом POST у вас нет ограничений, и ваш контент не нужно изменять или каким-либо образом манипулировать им.
остальное — В чем разница между POST и PUT в HTTP?
Читатели, плохо знакомые с этой темой, будут поражены бесконечными дискуссиями о том, что вам следует делать, и относительным отсутствием уроков из опыта. Тот факт, что REST «предпочтительнее» SOAP, я полагаю, является высокоуровневым обучением на собственном опыте, но, черт возьми, мы должны были продвинуться дальше? Это 2016 год.
Диссертация Роя была в 2000 году. Что мы разработали? Это было весело? Легко ли было интегрироваться? Поддерживать? Справится ли он с ростом числа смартфонов и нестабильной мобильной связью?
Согласно МЭ, реальные сети ненадежны. Тайм-аут запросов. Соединения сбрасываются. Сети отключаются на несколько часов или дней. Поезда входят в туннели с мобильными пользователями на борту. Для любого данного запроса (как иногда признается во всем этом обсуждении) запрос может упасть в воду на своем пути, или ответ может упасть в воду на обратном пути. В этих условиях выдача запросов PUT, POST и DELETE непосредственно к основным ресурсам всегда казалась мне несколько грубой и наивной.
HTTP ничего не делает для обеспечения надежного завершения запроса-ответа, и это нормально, потому что это работа сетевых приложений. Разрабатывая такое приложение, вы можете прыгать через обручи, чтобы использовать PUT вместо POST, а затем еще больше обручей, чтобы выдать определенную ошибку на сервере, если вы обнаружите повторяющиеся запросы.
Вернувшись к клиенту, вам придется прыгать через обручи, чтобы интерпретировать эти ошибки, обновлять, повторно проверять и публиковать.
Или вы можете сделать это : считайте ваши небезопасные запросы эфемерными однопользовательскими ресурсами (назовем их действиями). Клиенты запрашивают новое «действие» над основным ресурсом с пустым POST-запросом к ресурсу. POST будет использоваться только для этого. Получив безопасный URI только что созданного действия, клиент отправляет небезопасный запрос к URI действия, , а не к целевому ресурсу . Разрешение действия и обновление «реального» ресурса — это работа вашего API, и здесь она отделена от ненадежной сети.
Сервер делает свое дело, возвращает ответ и сохраняет его по согласованному URI действия . Если что-то пойдет не так, клиент повторяет запрос (естественное поведение!), а если сервер уже его увидел, повторяет сохраненный ответ и больше ничего не делает .
Вы быстро заметите сходство с обещаниями: мы создаем и возвращаем заполнитель для результата, прежде чем что-либо делать.
Так же, как и обещание, действие может быть выполнено успешно или неудачно один раз, но его результат может быть получен многократно.
Лучше всего то, что мы даем отправляющим и принимающим приложениям возможность связать уникально идентифицированное действие с уникальностью в соответствующих средах. И мы можем начать требовать и добиваться! ответственного поведения от клиентов: повторяйте свои запросы столько раз, сколько хотите, но не приступайте к созданию нового действия, пока не получите окончательный результат из существующего.
Таким образом, многие острые проблемы уходят. Повторяющиеся запросы на вставку не создают дубликатов, и мы не создаем настоящий ресурс, пока не получим данные. (столбцы базы данных могут оставаться необнуляемыми). Повторные запросы на обновление не приведут к несовместимым состояниям и не перезапишут последующие изменения. Клиенты могут (повторно) получать и беспрепятственно обрабатывать исходное подтверждение по любой причине (сбой клиента, пропажа ответа и т.