Метод post

Метод POST используется для запроса, при котором адресуемый сервер принимает объект, включенный в запрос, как новое подчинение (subordinate) ресурса, идентифицированного запрашиваемым URI (Request-URI) в строке запроса (Request-Line).

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

Метод put.

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

Фундаментальное различие между запросами POST и PUT, отражено в различном значении запрашиваемого URI (Request-URI). URI в запросе POST идентифицирует ресурс, который обрабатывает включенный объект. Этим ресурсом может быть процесс, принимающий данные, шлюз к некоторому другому протоколу, или отдельный объект, который принимает аннотации (accepts annotations). Напротив, URI в запросе PUT идентифицирует объект включенный в запрос - агент пользователя назначает данный URI включенному ресурсу, а сервер не должен пытаться применить запрос к некоторому другому ресурсу.

Метод delete.

Метод DELETE запрашивает первоначальный сервер об удалении ресурса, идентифицируемого запрашиваемым URI (Request-URI). Этот метод может быть отменен человеческим вмешательством (или другими средствами) на первоначальном сервере. Клиенту нельзя гарантировать, что операция была выполнена, даже если код состояния, возвращенный первоначальным сервером указывает на то, что действие было завершено успешно. Однако, серверу не следует отвечать об успешном выполнении, если во время формирования ответа он только собирается удалить ресурс или переместить его в недоступное положение.

Кэширование в http.

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

Цель кэширования в HTTP/1.1 состоит в том, чтобы устранить потребность посылки запросов во многих случаях, и устранить потребность посылки полных ответов в других случаях. Кэширование уменьшает число пересылок информации по сети, требуемых для многих действий; мы используем для этой цели механизм "устаревания" ("expiration").

Протокол HTTP/1.1 предоставляет следующие важные элементы:

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

2. Возможности протокола, которые позволяют первоначальному серверу или агенту пользователя явно запрашивать непрозрачное функционирование и управлять им.

3. Возможности протокола, которые позволяют кэшу присоединять к ответам предупреждения о том, что запрошенный уровень семантической прозрачности не сохранен.