В чем отличие метода PUT и PATCH?

Это шаблон, а шаблон может диктовать, что протокол stateless.

Какой протокол? Сферический в вакууме? Хорошо, если я реализую REST, то я вправе определить свой протокол, который соответствует REST требованиям. Так? Т.е. я определяю, что в моём протоколе есть сущности апи, а что нет, что является stored context on the server, а что нет.

Раз у апи lastfm написано, что оно рест, я уже знаю, что если соединение отвалилось, мне надо просто повторить запрос в новом, не выставляя заново какие-то настройки.

Нет, ты не можешь этого знать. «соединение отвалилось» - плохой пример. Давай лучше предположим, что вышло время жизни аксес токена. Из одного только «у нас рест», ты не можешь узнать является ли с точки зрения их реализации токен и всё что к нему вяжется на стороне сервера сущностями апи и не знаешь являются ли какие-то настройки тем самым контекстом, который противоречит требованию быть stateless или нет. И поэтому не знаешь нужно ли тебе опять выставлять настройки после получения нового аксесс токена или нет. Ты это можешь узнать из документации к апи, но из одной только фразы «у нас рест, ребята» ты такой вывод сделать не можешь.

Этот язык применится на вообще все запросы апи, на запросы токена, который выполнил запрос, или же на запросы получения инфы из профиля этого юзера?

Либо первое, либо второе. Ни в том ни в другом случае нельзя сказать будет ли это stateless или нет. В обоих случаях я могу сказать, что вы ничего не понимаете, что это у меня просто такой протокол, и я так вижу.

Т.е. я определяю, что в моём протоколе есть сущности апи, а что нет

В принципе ты даже можешь натянуть сову на глобус, если очень надо ;)

Либо первое, либо второе.

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

Допустим второе. Так делают, вот HTTP stateless, но прикручивают сессию через хранение в куках идентификатора сессии. Оно как бы прикручено сбоку и не входит в стандарт HTTP, поэтому таки выходит, что сам HTTP stateless.

Но если это просто язык, на каком выдавать результат, то самый тру вариант для stateless это передавать его параметром каждый раз. Так тоже делают, и это имеет свои преимущества, потому что сессия может протухнуть, и это надо как-то отслеживать и все настройки повторять, что лишний гемор.

Есть только get и post. Остальное маргинальщина.

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

А теперь представь, что это не язык, а количество лайков у статьи. Один юзер изменяет количество лайков - все остальные это видят. Чем этот пример принципиально отличается? Ничем.

Допустим второе. Так делают, вот HTTP stateless, но прикручивают сессию через хранение в куках идентификатора сессии. Оно как бы прикручено сбоку и не входит в стандарт HTTP, поэтому таки выходит, что сам HTTP stateless.

Только мы говорим не про HTTP, а про REST протокол - неведомое нечто. У http есть спека, там всё чётко и понятно, что является частью протокола, что нет. Когда мы говорим о протоколе конкретного веб приложения/сервиса, реализующего REST, то без спецификации этого протокола вообще непонятно как можно говорить о каком-то stateless свойстве этого протокола.

Но если это просто язык, на каком выдавать результат, то самый тру вариант для stateless это передавать его параметром каждый раз.

Я знаю, я сам так и делаю с языком в своих проектах. Но это не значит, что запоминание выбора языка на сервере - это stateful. Ничего вообще нельзя однозначно сказать пока не определён протокол о котором идёт речь. Например, если речь идёт не о запоминании языка, а о каком-то файле размером в несколько мегабайт, то отправлять его при каждом запросе будет не целесообразно, и автор протокола может запросто просто сказать, что это всё не часть протокола и поэтому его протокол stateless или наоборот скажет, что это часть протокола и тогда протокол будет stateful.

PUT идемпотентен

В чьей зоне ответственности данная проверка?

И зачем делать POST неидемпонентным? Ведь это грабли.

Семантические различия POST/PUT/PATCH

А если нужна еще одна семантическая операция, например закрытие счета?

PUT/PATCH - бесполезный хлам, за семантику должна отвечать пердметная область.

PUT используется для загрузки файлов:

PUT /path/to/upload/filename.txt HTTP/1.1
Host: govnosite.ru
...
Content-Type: text/plain; charset=utf-8
Content-Lenght: x

...

По указанному пути сервер должен создать файл.

PATCH же для обновления существующих объектов на сервере. Но так как многим похер на все эти рассуждения, то они используют PUT лишь потому что на 2 символа меньше печатать.

Компромисный вариант: используй метод PUTCH. Такой родной для русского сердца…

Все эти штуки так или иначе имеют отношения к БД.

• PUT – создание записи, ресурса, персоны и т.д.
• PATCH – изменение существующей
• GET – получение, возможно кэширование и управление кэшированием
• DELETE – удаление

Верно?

Да

Тогда какие ответы и коды должны быть в PATCH, если записи нет?

404 Not Found

и в PUT какие ответы должны быть при наличии записи и при ее отсутствии?

При отсутствии, проверка запроса и создание. Ответ 201 Created. При наличии – 409 Conflict.

А если нужна еще одна семантическая операция, например закрытие счета?

DELETE больше подходит к удаления ресурса. Если закрытие счёта не считается удалением – то PATCH – изменение. Если семантическая путаница совсем кромешная, то POST и не парить голову.

А вообще методы можно и свои придумывать, выходя за REST (и выгребая потом). Тот же PUTCH, DEPUTCH, REPUTCH, JUSTMAKEITTHIS, SHUTUPANDTAKEMYDATA.

При отсутствии, проверка запроса и создание. Ответ 201 Created. При наличии – 409 Conflict.

еще один. на, дурилка, читай:

If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.