Методи RESTful API; ГОЛОВА І ВАРІАНТИ

Я пишу модуль RESTful API для програми в PHP, і я трохи змішаний з дієсловами HEADта OPTIONS.

• OPTIONS  Використовується для отримання доступних дієслів HTTP для даного ресурсу?
• HEAD Використовується для визначення того, чи доступний даний ресурс?

Якби хтось міг пояснити * ці дієслова, це було б дуже вдячне.

_{* Пояснення стосувалося архітектур RESTful API, що перевживають дієслова HTTP. З тих пір я прийшов до усвідомлення того, що , як HEADі OPTIONSповинен НЕ бути повторно визначив, і замість того, щоб вести себе передбачувано , як будь-який додаток HTTP повинен. О, як ми зростаємо за 2 роки.}

Відповідно до: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

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 ПОВИННА включати будь-які поля заголовка, які вказують необов’язкові функції, реалізовані сервером і застосовні до цього ресурсу (наприклад, Дозволити), можливо, включаючи розширення, не визначені цією специфікацією. Орган відповіді, якщо такий є, ПОВИНЕН включати інформацію про варіанти зв'язку. Формат такого тіла не визначений цією специфікацією, але може бути визначений майбутніми розширеннями HTTP. Обговорення вмісту МОЖЕ бути використано для вибору відповідного формату відповіді. Якщо тіло відповіді не включено, відповідь ПОВИНЕН включати поле Content-Length із значенням поля "0".

Поле заголовка запиту Max-Forwards МОЖЕ бути використано для націлювання на конкретний проксі-сервер в ланцюжку запитів. Коли проксі-сервер отримує запит OPTIONS на absoluteURI, для якого дозволено пересилання запитів, проксі-сервер ПОВИНЕН перевірити наявність поля Max-Forwards. Якщо значення поля Max-Forwards дорівнює нулю ("0"), проксі НЕ ПОВИНЕН пересилати повідомлення; натомість проксі-сервер ПОВИНЕН реагувати власними параметрами зв'язку. Якщо значення поля Max-Forwards є цілим числом, більшим за нуль, проксі-сервер ПОВИНЕН зменшити значення поля при пересиланні запиту. Якщо в запиті немає поля Max-Forwards, то переадресований запит НЕ ПОВИНЕН включати поле Max-Forwards.

9.4 ГОЛОВА

Метод HEAD ідентичний GET, за винятком того, що сервер НЕ ПОВИНЕН повертати тіло повідомлення у відповіді. Інформація про метаінформацію, що міститься в заголовках HTTP у відповідь на запит HEAD, ПОВИННА ідентична інформації, надісланій у відповідь на запит GET. Цей метод може бути використаний для отримання інформації про сутність, передбачену запитом, без передачі самого органу сутності. Цей метод часто використовується для перевірки гіпертекстових посилань на валідність, доступність та останні модифікації.

Відповідь на запит HEAD МОЖЕ бути кешованою в тому сенсі, що інформація, що міститься у відповіді, МОЖЕ бути використана для оновлення раніше кешованої сутності з цього ресурсу. Якщо нові значення полів вказують на те, що кешована сутність відрізняється від поточної сутності (як це було б показано зміною Content-Length, Content-MD5, ETag або Last-Modified), тоді кеш ПОВИНЕН розглядати запис кешу як застарілий.

OPTIONSметод повертає інформацію про API (методи / тип вмісту)

HEADметод повертає інформацію про ресурс (версія / довжина / тип)

Відповідь сервера

ВАРІАНТИ

HTTP/1.1 200 OK
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:24:43 GMT
Content-Length: 0

ГОЛОВА

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/html; charset=UTF-8
Date: Wed, 08 May 2013 10:12:29 GMT
ETag: "780602-4f6-4db31b2978ec0"
Last-Modified: Thu, 25 Apr 2013 16:13:23 GMT
Content-Length: 1270

• OPTIONS Визначення, які методи HTTP підтримує ресурс, наприклад, чи можемо ми його ВИДАЛИТИ або оновити через PUT?
• HEADПеревірка, чи не змінився ресурс. Це корисно при підтримці кешованої версії ресурсу
• HEAD Отримання метаданих про ресурс, наприклад, тип носія чи його розмір, перед тим, як зробити можливо дорогоцінним пошуком
• HEAD, OPTIONSПеревірка того, чи існує ресурс та чи є він доступним. Наприклад, перевірка посилань, поданих користувачем, у програмі

Ось приємна та стисла стаття про те, як HEAD та OPTIONS вписуються в архітектуру RESTful.

OPTIONS повідомляє вам такі речі, як "Які методи дозволені для цього ресурсу".

HEAD отримує заголовок HTTP, який ви отримали б, якщо зробили запит GET, але без основного тексту. Це дозволяє клієнту визначити інформацію кешування, який тип вмісту буде повернуто, який код стану буде повернено. Наявність - це лише незначна його частина.