Цей пост – відповідь на запитання, задане у коментарі до однієї з моїх статей.
У статті я хочу розповісти, що ж собою представляють HTTP-методи GET/POST/PUT/DELETE та інші, для чого вони були придумані і як їх використовувати відповідно до REST.
HTTP
Отже, що ж являє собою один із основних протоколів інтернету? Педантів відправлю до RFC2616, а іншим розповім по-людськи:)Цей протокол описує взаємодію між двома комп'ютерами (клієнтом і сервером), побудоване з урахуванням повідомлень, званих запит (Request) і відповідь (Response). Кожне повідомлення складається з трьох частин: стартовий рядок, заголовки та тіло. При цьому обов'язковим є лише стартовий рядок.
Стартові рядки для запиту та відповіді мають різний формат - нам цікавий тільки стартовий рядок запиту, який виглядає так:
METHOD URI HTTP/ VERSION ,
Де METHOD – це якраз метод HTTP-запиту, URI – ідентифікатор ресурсу, VERSION – версія протоколу (на даний момент актуальна версія 1.1).
Заголовки - це набір пар ім'я-значення, розділених двокрапкою. У заголовках передається різна службова інформація: кодування повідомлення, назва та версія браузера, адреса, з якої прийшов клієнт (Referrer) тощо.
Тіло повідомлення - це, власне, дані, що передаються. У відповіді переданими даними, зазвичай, є html-сторінка, яку запросив браузер, а запиті, наприклад, у тілі повідомлення передається вміст файлів, завантажуваних на сервер. Але, як правило, тіло повідомлення у запиті взагалі відсутнє.
Приклад HTTP взаємодії
Розглянемо приклад.Запит:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Перший рядок – це рядок запиту, інші – заголовки; тіло повідомлення відсутнє
Відповідь:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: uk Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТОРІНКА...
Ресурси та методи
Повернемося до стартового рядка запиту і пригадаємо, що в ньому є такий параметр, як URI. Це розшифровується як Uniform Resource Identifier - одноманітний ідентифікатор ресурсу. Ресурс - це, як правило, файл на сервері (приклад URI в даному випадку "/styles.css"), але взагалі ресурсом може бути якийсь абстрактний об'єкт ("/blogs/webdev/" - вказує на блок «Веб- технологія», а не на конкретний файл).Тип HTTP-запиту (також званий HTTP-метод) вказує серверу те що, яку ми хочемо зробити з ресурсом. Спочатку (на початку 90-х) передбачалося, що клієнт може хотіти від ресурсу лише одне – отримати його, проте зараз за протоколом HTTP можна створювати пости, редагувати профіль, видаляти повідомлення та багато іншого. І ці дії складно поєднати терміном «отримання».
Для розмежування дій із ресурсами лише на рівні HTTP-методів і було придумано такі варианты:
- GET – отримання ресурсу
- POST - створення ресурсу
- PUT – оновлення ресурсу
- DELETE – видалення ресурсу
У гру вступає REST
REST (REpresentational State Transfer) - це термін було введено в 2000-му році Роєм Філдінгом (Roy Fielding) - одним з розробників протоколу HTTP - як назву групи принципів побудови веб-додатків. Взагалі REST охоплює ширшу область, ніж HTTP - його можна використовувати й інших мережах з іншими протоколами. REST описує принципи взаємодії клієнта і сервера, засновані на поняттях «ресурсу» та «дієслова» (можна розуміти їх як підмет і присудок). У разі HTTP ресурс визначається своїм URI, а дієслово – це HTTP-метод.REST пропонує відмовитися від використання однакових URI для різних ресурсів (тобто адреси двох різних статей на кшталт /index.php?article_id=10 та /index.php?article_id=20 - це не REST-way) і використовувати різні HTTP-методи для різних дій. Тобто веб-додаток, написаний з використанням REST підходу, буде видаляти ресурс при зверненні до нього з HTTP-методом DELETE (зрозуміло, це не означає, що треба давати можливість видалити все і вся, але будь-якийзапит на видалення у додатку повинен використовувати HTTP-метод DELETE).
REST дає програмістам можливість писати стандартизовані та трохи красивіші веб-додатки, ніж раніше. Використовуючи REST, URI додавання нового користувача буде не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).
У результаті, поєднавши наявну специфікацію HTTP і REST-підхід знаходять сенс різні HTTP-методи. GET – повертає ресурс, POST – створює новий, PUT – оновлює існуючий, DELETE – видаляє.
Проблеми?
Так, є невелика проблема із застосуванням REST на практиці. Проблема ця називається HTML.PUT/DELETE запити можна надсилати за допомогою XMLHttpRequest, за допомогою звернення до сервера "вручну" (скажімо, через curl або навіть через telnet), але не можна зробити HTML-форму, яка надсилає повноцінний PUT/DELETE-запит.
Справа в тому, що специфікація HTML не дозволяє створювати форми, що відправляють дані інакше, ніж через GET або POST. Тож нормальної роботи з іншими методами доводиться імітувати їх штучно. Наприклад, в Rack (механізм, на базі якого Ruby взаємодіє з веб-сервером; із застосуванням Rack зроблені Rails, Merb та інші Ruby-фреймворки) у форму можна додати hidden-поле з ім'ям "_method", а як значення вказати назву методу (наприклад, «PUT») - у цьому випадку буде відправлено POST-запит, але Rack зможе вдати, що отримав PUT, а не POST.
Усі дані в рамках Web-технології передаються за протоколом HTTР. Виняток становить обмін з використанням програмування Java або обмін з Plugin-додатків. Враховуючи реальний обсяг трафіку, який передається в рамках Web-обміну по HTTP, ми розглядатимемо лише цей протокол. При цьому ми зупинимося на таких питаннях, як:
- загальна структура повідомлень;
- методи доступу;
- Оптимізація обмінів.
Загальна структура повідомлень
HTTP- Це протокол прикладного рівня. Він орієнтований модель обміну " клієнт-сервер " . Клієнт та сервер обмінюються фрагментами даних, які називаються HTTP-повідомленнями. Повідомлення, що надсилаються клієнтом серверу, називають запитами, а повідомлення, що надсилаються сервером клієнту - відгуками. Повідомлення може складатися з двох частин: заголовка та тіла. Тіло від заголовка відокремлюється порожнім рядком.
Заголовок містить службову інформацію, необхідну обробки тіла повідомлення чи управління обміном. Заголовок складається з директив заголовка, які зазвичай записуються кожна на новому рядку.
Тіло повідомлення не обов'язкове, на відміну від заголовка повідомлення. Воно може містити текст, графіку, аудіо або відеоінформацію.
Нижче наведено HTTP-запит:
GET / HTTP/1.0 Accept: image/jpeg порожній рядок
І відгук:
HTTP/1.0 200 OK Дата: Fri, 24 Jul 1998 21:30:51 GMT Server: Apache/1.2.5 Content-type: text/html Content-length: 21345 порожній рядок ...
Текст "порожній рядок" - це просто позначення наявності порожнього рядка, який відокремлює заголовок HTTP-повідомлення від його тіла.
Сервер, приймаючи запит від клієнта, частина інформації заголовка HTTP-запиту перетворює на змінні оточення, які доступні для аналізу CGI-скриптом . Якщо запит має тіло, воно стає доступним скрипту через потік стандартного введення.
Методи доступу
Найголовнішою директивою HTTP-запиту є метод доступу. Він вказується першим словом у першому рядку запиту. У нашому прикладі це GET. Розрізняють чотири основні методи доступу:
- HEAD;
- POST;
Крім цих чотирьох методів, існує ще близько п'яти додаткових методів доступу, але вони використовуються рідко.
Метод GET
Метод GET застосовується клієнтом за запитом до сервера за промовчанням. У цьому випадку клієнт повідомляє адресу ресурсу (URL), яку він хоче отримати, версію протоколу HTTP , підтримувані ним MIME-типи документів, версію та назву клієнтського програмного забезпечення. Всі ці параметри вказуються в заголовку запиту HTTP. Тіло у запиті не передається.
У відповідь сервер повідомляє версію протоколу HTTP, код повернення, тип вмісту тіла повідомлення, розмір тіла повідомлення та ряд інших необов'язкових директив HTTP-заголовка. Сам ресурс, зазвичай HTML-сторінка, передається у тілі відгуку.
Метод HEAD
Метод HEAD використовується зменшення обмінів під час роботи з протоколу HTTP . Він аналогічний методу GET крім того, що у відгуку тіло повідомлення не передається. Цей метод використовується для перевірки часу останньої модифікації ресурсу та терміну придатності кешованих ресурсів, а також під час використання програм сканування ресурсів World Wide Web. Одним словом, метод HEAD призначений для зменшення обсягу інформації, що передається по мережі в рамках HTTP-обміну.
Метод POST
Метод POST - це альтернатива методу GET. При обміні даними за методом POST у запиті клієнта є тіло HTTP-повідомлення. Це тіло може формуватися з даних, що вводяться в HTML-формі, або з зовнішнього приєднаного файлу. У відгуку, як правило, є і заголовок, і тіло HTTP-повідомлення. Щоб ініціювати обмін методом POST , в атрибуті METHOD контейнера FORM слід вказати значення " post " .
Метод PUT
Метод PUT використовується для публікації HTML-сторінок у каталозі HTTP-сервера. При передачі даних від клієнта до сервера в повідомленні присутній і заголовок повідомлення, в якому вказано URL цього ресурсу, і тіло - зміст ресурсу, що розміщується.
У відгуку тіло ресурсу зазвичай не передається, а заголовку повідомлення вказується код повернення, який визначає успішне чи неуспішне розміщення ресурсу.
Оптимізація обмінів
Протокол HTTP спочатку не був орієнтований на постійне з'єднання. Це означає, що коли сервер прийняв запит від клієнта і відповів на нього, з'єднання між клієнтом і сервером розривається. Для нового обміну даними необхідно встановити нове з'єднання. Такий підхід має як переваги, так і недоліки.
До переваг належить можливість одночасного обслуговування великої кількості коротких запитів. Навіть на популярних серверах кількість відкритих з'єднань може не перевищувати сотні при обслуговуванні близько мільйона запитів на добу. При цьому один клієнт може відкрити до 40 з'єднань одночасно, і з погляду сервера всі вони є рівноправними. При високошвидкісних лініях зв'язку це дозволяє досягти малого часу відгуку запит клієнта для всієї сторінки (текст, графіка тощо.).
До недоліків такої схеми обміну належать: необхідність щоразу встановлювати з'єднання та неможливість підтримувати сесію роботи з інформаційним ресурсом. При ініціалізації з'єднання транспортного протоколу TCP і розриві цього з'єднання потрібно передати досить великий обсяг службової інформації. Відсутність підтримки сесій у HTTP ускладнює роботу з такими ресурсами як бази даних або ресурси, які потребують автентифікації.
Для оптимізації числа відкритих TCP-з'єднань у протоколі HTTP версій 1.0 і 1.1 передбачений режим keep-alive. У цьому режимі з'єднання ініціалізується лише один раз, і по ньому можна послідовно реалізувати кілька HTTP-обмінів.
Для забезпечення підтримки сесій до директив HTTP-заголовка були додані "печенюшки" (cookies). Вони дозволяють зімітувати підтримку з'єднання під час роботи за протоколом HTTP.
Види інтерфейсу користувача у Web-технології
Сторінки World Wide Web за функціональним призначенням можна розділити на кілька типів: інформаційні сторінки, навігаційні сторінки, сторінки обміну даними. У багатьох випадках ці функції можна об'єднати на одній сторінці.
Інформаційні сторінки – це послідовне викладення інформації з можливістю гіпертекстових контекстних переходів. Користувач переглядає їх послідовно. Гіпертекстові посилання зазвичай застосовують для створення виносок, приміток чи посилань до списків літератури та інших асоціативних матеріалів. Типовими прикладами таких сторінок є підказки, посібники, описи компаній, історичні довідки тощо.
Навігаційні сторінки - це сукупність гіпертекстових посилань, що дозволяє орієнтуватися у матеріалах Web-вузла. Типовий приклад такої сторінки – Home page (домашня сторінка). Як правило, на ній немає великих текстових описів та ілюстрацій, вона складається з сукупності різних меню. Ці меню можна реалізувати через списки, таблиці посилань або imagemap.
Сторінки обміну даними дозволяють передати на сервер певний обсяг інформації, відмінний від стандартної адреси (URL) ресурсу. При перегляді та навігації користувач просто вибирає гіпертекстові посилання, за якими завантажуються нові сторінки. При обміні даними на сервер передається як адресу ресурсу, а й додаткова інформація, яку вводить користувач.
Залежно від функціонального призначення сторінок змінюється вигляд інтерфейсу ресурсу, з яким користувач має справу. У перших двох випадках достатньо маніпулятором "миша" вибрати гіпертекстове посилання, як відразу завантажиться нова сторінка. У разі сторінок обміну даними слід заповнити поля HTML-форм та надіслати дані на сервер.
При цьому форми забезпечують практично всі необхідні види полів введення та меню. Єдине, чого не дозволяють реалізувати HTML-форми, так це вкладені меню. Форми можна застосовувати як під час обміну даними. Досить розвинені механізми обробки форм є у JavaScript.
Протокол передачі гіпертексту (HTTP) – це основа життя в Інтернеті. Він використовується щоразу при передачі документа або у запиті AJAX. Але HTTP напрочуд мало відомий деяким веб-розробникам.
У цьому вступі ми познайомимося з принципами розробки REST, що лежать в основі HTTP та використання їх потужності для створення інтерфейсів, які можуть виконуватися практично з будь-якого пристрою чи операційної системи.
Перевиданий урок
Кожні кілька тижнів ми переглядаємо деякі улюблені повідомлення наших читачів за всю історію сайту. Цей урок вперше було опубліковано у листопаді 2010 року.
Чому REST?
REST – простий спосіб організації взаємодії між незалежними системами.
REST – простий спосіб організації взаємодії між незалежними системами. Він користується популярністю з 2005 року та надихає дизайн сервісів, таких як API Twitter. Завдяки тому, що REST забезпечує взаємодію з такими різноманітними клієнтами, як мобільні телефони та інші веб-сайти. Теоретично REST не прив'язаний до мережі, але майже завжди реалізований як такий і був натхненний HTTP. В результаті REST можна використовувати скрізь, де можливе HTTP.
Альтернативою є створення щодо складних угод над HTTP. Часто це набуває форми нових XML-мов. Найяскравіший приклад - SOAP. Вам потрібно вивчити абсолютно новий набір угод, але ви ніколи не використовуєте HTTP на повну силу. Оскільки REST був натхненний HTTP і грає на його сильні сторони, це найкращий спосіб дізнатися, як працює HTTP.
Після початкового огляду ми розглянемо кожен із будівельних блоків HTTP: URL-адреси, HTTP-команди та коди відповідей. Ми також розглянемо, як використовувати їх у RESTful. Принагідно ми проілюструємо теорію прикладом програми, яка імітує процес відстеження даних, пов'язаних із клієнтами компанії через веб-інтерфейс.
HTTP
HTTP – це протокол, який дозволяє надсилати документи в Інтернеті.
HTTP – це протокол, який дозволяє надсилати документи в Інтернеті. Протокол - це набір правил, визначальних, які можна обмінювати, і які повідомлення є відповідними відповідями іншим. Іншим поширеним протоколом є POP3, який ви можете використовувати для отримання електронної пошти на жорсткому диску.
У HTTP є дві різні ролі: сервер та клієнт. Як правило, клієнт завжди ініціює розмову; сервер відповідає. HTTP базується на тексті; тобто повідомлення насправді є бітами тексту, хоча тіло повідомлення може також містити інші носії. Використання тексту дозволяє легко відстежувати обмін HTTP.
HTTP-повідомлення складаються із заголовка та тіла. Тіло часто може залишатися порожнім; воно містить дані, які ви хочете передати по мережі, щоб використовувати їх відповідно до інструкцій у заголовку. Заголовок містить метадані, наприклад, інформацію про кодування; але у разі запиту він також містить важливі HTTP-методи. У стилі REST ви виявите, що ці заголовки часто більш значущі, ніж тіла.
Шпигунство HTTP на роботі
Якщо ви використовуєте Chrome Developer Tools або Firefox з розширенням Firebug, клацніть на панелі Net і встановіть його в enabled. Після цього ви зможете переглядати інформацію про HTTP-запити в міру вашого пошуку. Наприклад:
Іншим корисним способом ознайомитися з HTTP є використання виділеного клієнта, такого як cURL.
GET
GET – це найпростіший тип HTTP-запиту; яким браузер користується щоразу, коли ви натискаєте посилання або вводите URL-адресу в адресний рядок. Він інструктує сервер надсилати клієнту дані, ідентифіковані URL-адресою. Ніколи не буде змінено дані на стороні сервера в результаті запиту GET . У цьому сенсі GET -запит доступний тільки для читання, але, звичайно, як тільки клієнт отримає дані, він може самостійно виконувати будь-які операції з ними, наприклад, форматувати для відображення.
PUT
Запит PUT використовується, коли ви хочете створити або оновити ресурс, вказаний URL-адресою. Наприклад,
PUT /clients/robin
може створити клієнта з ім'ям Robin на сервері. Ви помітите, що REST повністю незалежний від бекенда; у запиті немає нічого, що інформує сервер про те, як дані мають створюватися - просто так має бути. Це дозволяє легко змінювати базову технологію за потребою. Запити PUT містять дані для використання при оновленні або створенні ресурсу body. У cURL можна додати дані в запит за допомогою -d .
Curl -v -X PUT -d "some text"
DELETE
DELETE повинен виконувати протилежне PUT; його слід використовувати, якщо ви бажаєте видалити ресурс, вказаний URL-адресою запиту.
Curl -v -X DELETE /clients/anne
Це призведе до видалення всіх даних, пов'язаних із ресурсом, ідентифікованих /clients/anne .
POST
POST використовується, коли обробка, яку ви хочете виконати на сервері, повинна повторюватися, якщо запит POST повторюється (тобто вони не є ідемопотентними, Докладніше про це нижче). Крім того, запити POST повинні викликати обробку body запиту як підпорядкованої URL-адреси, яку ви відправляєте.
Простіше кажучи:
POST /clients/
не повинен викликати зміну ресурсу в /clients/ сам, але ресурс URL починається з нього/clients/. Наприклад, він може додати до списку нового клієнта, з id згенерованим сервером.
/clients/some-unique-id
Запити PUT легко використовують замість запитів POST і навпаки. Деякі системи використовують лише один, деякі використовують POST для створення операцій та PUT для операцій оновлення (оскільки із запитом PUT ви завжди вказуєте повну URL-адресу), деякі використовують POST для оновлень та PUT для створення.
Часто запити POST використовуються для запуску операцій на сервері, які не вписуються у парадигму Create/Update/Delete; але це, однак, виходить за рамки REST. У нашому прикладі ми будемо повністю дотримуватися PUT.
Класифікація методів HTTP
Безпечні та небезпечні методи:
безпечними є методи, які ніколи не змінюють ресурси. Єдиними безпечними методами, з чотирьох перерахованих вище, є GET. Інші небезпечні, оскільки можуть призвести до модифікації ресурсів.
Idempotent методи:Ці методи досягають того ж результату, незалежно від того, скільки разів запит повторюється: це GET, PUT та DELETE. Єдиним неідемпотентним методом є POST. PUT і DELETE, які вважаються ідемпотентами, можуть бути несподіваними, хоча, насправді, це досить легко пояснити: повторення методу PUT з таким самим body має модифікувати ресурс таким чином, щоб він залишався ідентичним описаному в попередньому запиті PUT: нічого не зміниться! Аналогічно, немає сенсу двічі видаляти ресурс. З цього випливає, що незалежно від того, скільки разів запит PUT або DELETE повторюється, результат повинен бути таким самим, якби це було зроблено лише один раз.
Пам'ятайте: саме ви, програміст, зрештою вирішуєте, що відбувається, коли використовується певний HTTP-метод. У реалізаціях HTTP немає нічого, що автоматично призведе до створення ресурсів, їх перерахування, видалення чи оновлення. Ви повинні бути обережними, щоб правильно застосовувати HTTP-протокол і вводити цю семантику самостійно.
Представництва
HTTP-клієнт та HTTP-сервер обмінюються інформацією про ресурси, визначені URL-адресами.
Ми можемо підсумовувати те, що ми дізналися до цих пір, так: HTTP-клієнт та HTTP-сервер обмінюються інформацією про ресурси, визначені URL-адресами.
Ми говоримо, що запит та відповідь містять подання ресурсу. Під уявленням ми маємо на увазі інформацію у певному форматі про стан ресурсу або про те, яким цей стан має бути в майбутньому. Обидва і header, і body - є частинами уявлення.
Заголовки HTTP, що містять метадані, жорстко визначаються специфікацією HTTP; вони можуть містити лише простий текст і мають бути відформатовані певним чином.
Тіло може містити дані у будь-якому форматі, і саме тут видно силу HTTP. Ви знаєте, що можете надсилати простий текст, зображення, HTML та XML будь-якою людською мовою. Через метадані запиту або різні URL-адреси можна вибирати між різними уявленнями для одного і того ж ресурсу. Наприклад, ви можете надіслати веб-сторінку до браузера та JSON до програм.
HTTP-відповідь має вказувати тип вмісту body. Це робиться у заголовку, у полі Content-Type; наприклад:
Content/Type: application/json
Для простоти наш додаток тільки відправляє JSON туди і назад, але програма повинна бути спроектована таким чином, щоб ви могли легко змінювати формат даних, щоб адаптуватися для різних клієнтів або уподобань користувача.
Бібліотеки клієнта HTTP
cURL - це найчастіше HTTP-рішення для PHP-розробників.
Щоб експериментувати з різними методами запиту, вам потрібен клієнт, який дозволить вказати, який метод використовувати. На жаль, форми HTML не підходять для рахунку, оскільки вони дозволяють робити лише запити GET та POST. У реальному житті API-інтерфейси доступні програмно через окрему клієнтську програму або через JavaScript у браузері.
Саме тому на додаток до сервера важливо мати хороші можливості HTTP-клієнта вибраною мовою програмування.
Дуже популярна клієнтська HTTP-бібліотека, знову ж таки, cURL. Ви вже були ознайомлені з командою cURL у цьому уроці. CURL включає як автономну програму командного рядка, так і бібліотеку, яка може використовуватися різними мовами програмування. Зокрема, cURL є найчастіше ідеальним рішенням HTTP-клієнта для розробників PHP. Інші мови, такі як Python, пропонують більше своїх клієнтських HTTP-бібліотек.
Налаштування прикладу програми
Я хочу показати якомога нижчий рівень функціональності.
Наш приклад PHP-програми надзвичайно худий. Я хочу виставити якомога більш низькорівневу функціональність, без будь-якої магії framework. Я також не хотів використовувати цей API, наприклад, Twitter, тому що вони можуть несподівано змінюватися, вам потрібно налаштувати автентифікацію, що може бути проблемою і ви не зможете вивчити реалізацію.
Щоб запустити приклад програми, необхідно встановити PHP5 і веб-сервер з механізмом для запуску PHP. Поточна версія повинна бути не нижче версії 5.2, щоб мати доступ до функцій json_encode() та json_decode().
Що стосується серверів, найбільш поширеним варіантом є Apache з mod_phpале ви можете використовувати будь-які альтернативи, які вам зручні. Існує приклад конфігурації Apache, який містить правила перезапису, які допоможуть вам швидко налаштувати програму. Всі запити до будь-якого URL, починаючи з /clients/, повинні бути надіслані в наш файл server.php.
В Apache вам потрібно ввімкнути mod_rewriteі помістити конфігурацію, що додається mod_rewriteде-небудь у вашій конфігурації Apache або ваш файл .htacess. Таким чином, server.phpбуде відповідати на всі запити, що надходять із сервера. Це ж має бути досягнуто з Nginx, або з будь-яким іншим сервером, який ви вирішите використовувати.
Як працює приклад програми
Є два ключі для обробки запитів REST. Перший ключ - ініціювати різну обробку залежно від методу HTTP, навіть коли URL-адреси однакові. У PHP у глобальному масиві $_SERVERє змінна, яка визначає, який метод був використаний для виконання запиту:
$_SERVER["REQUEST_METHOD"]
Ця змінна містить ім'я методу у вигляді рядка, наприклад "GET", "PUT" і далі.
Інший ключ - дізнатися, який URL було запрошено. Для цього ми використовуємо іншу стандартну змінну PHP:
$_SERVER["REQUEST_URI"]
Ця змінна містить URL-адресу, що починається з першої косої межі. Наприклад, якщо ім'я хоста - "example.com", "http://example.com/" повернеться " / ", як " http://example.com/test/ " повернеться " /test/ ".
Давайте спочатку спробуємо визначити, яка URL-адреса була викликана. Ми розглядаємо тільки URL-адреси, що починаються з "clients". Решта недійсні.
$resource = array_shift($paths); if ($resource == "clients") ( $name = array_shift($paths); if (empty($name)) ( $this->handle_base($method); ) else ( $this->handle_name($method) , $name); ) ) else ( // We only handle resources under "clients" header("HTTP/1.1 404 Not Found"); )
У нас є два можливі результати:
- Ресурс – це клієнти, і в цьому випадку ми повертаємо повний перелік
- Існує ще один ідентифікатор
Якщо є ще один ідентифікатор, ми припускаємо, що це ім'я клієнта, і знову ж таки перенаправляємо його в іншу функцію, залежно від method . Ми використовуємо оператор switch, якого слід уникати в реальному додатку:
Switch($method) ( case "PUT": $this->create_contact($name); break; case "DELETE": $this->delete_contact($name); break; case "GET": $this->display_contact ($name); break; deader;
Коди відповідей
Коди відповіді HTTP стандартизують спосіб інформування клієнта про результат запиту.
Ви могли помітити, що приклад програми використовує PHP header() , передаючи деякі дивні рядки як аргументи. Функція header()друкує HTTP headers та гарантує, що вони відформатовані відповідним чином. Заголовки повинні бути першими у відповіді, тому не варто виводити щось ще до того, як ви закінчите із заголовками. Іноді ваш HTTP-сервер може бути налаштований для додавання інших заголовків на додаток до тих, що ви вказали в коді.
Сервер повинен повернути найбільш відповідний код відповіді HTTP; таким чином, клієнт може спробувати виправити свої помилки, якщо вони є. Більшість людей знайомі з поширеним кодом відповіді 404 Not Found, однак є багато більш доступних, відповідно до багатьох ситуацій.
Майте на увазі, що значення коду відповіді HTTP не є надзвичайно точним; це наслідок того, що HTTP сам собою досить загальний. Ви повинні спробувати знайти код відповіді, який найточніше відповідає ситуації. Але й не надто переживайте, якщо не зможете знайти точну відповідність.
Ось кілька HTTP-кодів відповіді, які часто використовуються з REST:
200 OK
Цей код відповіді вказує на те, що запит був успішним.
201 Created
Це означає, що запит був успішним і було створено ресурс. Він використовується у разі успіху запиту PUT або POST.
400 Bad Request
Запит було втрачено. Це відбувається особливо з запитами POST і PUT, коли дані не проходять валідацію або перебувають у неправильному форматі.
404 Not Found
Ця відповідь показує, що необхідного ресурсу не знайдено. Зазвичай це стосується всіх запитів, які вказують на URL-адресу без відповідного ресурсу.
401 Unauthorized
Ця помилка означає, що вам необхідно виконати автентифікацію перед доступом до ресурсу.
405 Method Not Allowed
Метод HTTP, що використовується, не підтримується для цього ресурсу.
409 Conflict
Це свідчить про конфлікт. Наприклад, ви використовуєте запит PUT для створення одного ресурсу двічі.
500 Internal Server Error
Коли все інше зазнає невдачі; як правило, відповідь 500 використовується, коли обробка завершується невдало через непередбачені обставини на стороні сервера, що викликає помилку сервера.
Виконання зразка програми
Давайте почнемо з простого вилучення інформації з програми. Нам потрібні деталі клієнта, "jim", тому відправимо простий запит GET на URL цього ресурсу:
Curl -v http://localhost:80/clients/jim
Це відображатиме повні повідомлення headers. Останнім рядком відповіді буде повідомлення body; у цьому випадку це буде JSON, що містить адресу Jim (пам'ятайте, що пропуск імені методу призведе до GET-запиту, а також замініть localhost: 80 на ім'я сервера та порт, який ви використовуєте).
Потім ми можемо отримати інформацію для всіх клієнтів одночасно:
Curl -v http://localhost:80/clients/
Щоб створити нового клієнта з ім'ям Paul ...
Curl -v -X PUT http://localhost:80/clients/paul -d "("address":"Sunset Boulevard" )
і ви отримаєте список всіх клієнтів, що містять Paul як підтвердження.
Нарешті, щоб видалити клієнта:
Curl -v -X DELETE http://localhost:80/clients/anne
Ви виявите, що повернутий JSON більше не містить жодних даних про Anne.
Якщо ви намагаєтеся отримати неіснуючого клієнта, наприклад:
Curl -v http://localhost:80/clients/jerry
Ви отримаєте помилку 404, тоді як при спробі створити вже існуючого клієнта:
curl -v -X PUT http://localhost:80/clients/anne
натомість отримайте помилку 409.
Висновок
Загалом чим менше припущень за межами HTTP ви робите, тим краще.
Важливо пам'ятати, що HTTP був задуманий взаємодії між системами, які ніщо не поділяє, крім розуміння протоколу. В цілому, чим менше припущень за межами HTTP ви робите, тим краще: це дозволяє широкому колу програм та пристроїв отримувати доступ до вашого API.
Я використовував PHP у цьому уроці, тому що це, швидше за все, мова, найбільш знайома читачам Nettuts +. Тим не менш, PHP, хоча і призначений для Інтернету, ймовірно, не найкраща мова для роботи при способі REST, оскільки він обробляє запити PUT зовсім інакше, ніж GET і POST.
Крім PHP, ви можете взяти до уваги наступне:
- Різні Ruby frameworks (Rails та Sinatra)
- Python має відмінну підтримку REST. Повинні працювати Plain Django та WebOb, або Werkzeug.
- node.js відмінно підтримує REST
Серед додатків, які намагаються дотримуватися принципів REST, класичним прикладом є Atom Publishing Protocol, хоча насправді він не використовується надто часто на практиці. За сучасною програмою, заснованою на філософії використання HTTP повною мірою, зверніться до Apache CouchDB .
612
HTTP PUT:
PUT містить файл або ресурс у певний URI, і саме на цьому URI. Якщо URI вже має файл або ресурс, PUT замінює цей файл або ресурс. Якщо немає файлу чи ресурсу, PUT створює його. PUT - idempotent, але, як не парадоксально, відповіді PUT не підлягають кешування.
HTTP POST:
POST відправляє дані на конкретний URI і чекає ресурсу на те, що URI для обробки запиту. Веб-сервер може визначити, що робити з даними в контексті зазначеного ресурсу. Метод POST не дорівнює idempotent, проте відповіді POST : кешуються, якщо сервер встановлює відповідні заголовки Cache-Control та Expires.
Офіційний HTTP RFC визначає POST бути:
- Анотація існуючих ресурсів;
- Публікація повідомлення на дошці оголошень, в групі новин, списку розсилки, або аналогічній групі статей;
- Надання блоку даних, таких як результат відправлення форми, процес обробки даних;
- Розширення бази даних за допомогою операції додавання.
Різниця між POST та PUT:
Сам RFC пояснює різницю ядра:
Фундаментальна різниця між POST та PUT запитів відображена у різне значення Request-URI. URI у запиті POST ідентифікує ресурс, який оброблятиме в'язень. Цей ресурс може бути процесом, що приймає дані, шлюзом до іншого протоколу або окремим об'єктом, який приймає анотації. На відміну від цього, URI у запиті PUT ідентифікує об'єкт, включений у запиті - агент користувача знає, що URI є призначений і сервер НЕ ПОВИНЕН спроби застосувати запит до деяких інших ресурсів. Якщо сервер бажає, щоб запит був застосований до іншого URI, він повинен відправити 301 (переміщену постійну) відповідь; користувача агент МОЖЕ потім зробити своїм власним рішенням щодо того, перенаправити запит чи ні.
Використовуючи правильний метод, не пов'язані осторонь:
Я отримую останнім часом досить дратує популярну помилку веб-розробників, що POST використовується для створення ресурсу, а PUT використовується для оновлення/зміни.
Якщо ви подивіться на сторінці 55 RFC 2616 («Протокол передачі гіпертексту - HTTP/1.1»), Section 9.6 («PUT»), ви побачите, що PUT насправді для:
Метод PUT запитує, щоб закритий об'єкт зберігався у запитаному Request-URI.
Там також зручний пункт, щоб пояснити різницю між POST та PUT:
Фундаментальна різниця між POST та PUT запитів знаходить своє відображення в іншому значенні Request-URI. URI у запиті POST ідентифікує ресурс, який оброблятиме в'язень. Цей ресурс може бути процесом прийняття даних, шлюзом до іншого протоколу або окремим об'єктом, який приймає інструкції. Навпаки, URI в запиті PUT ідентифікує об'єкт, укладений із запитом - користувач знає, що таке URI, і сервер НЕ ПОВИНЕН намагатися застосувати запит до іншого ресурсу.
У ньому нічого не говориться про різницю між оновленням/створенням, тому що це не те, про що йдеться. Йдеться про різницю між цим:
Obj.set_attribute(value) # A POST request.
Obj.attribute = value # A PUT request.
Тому, будь ласка, зупинити поширення цієї популярної помилки. Прочитайте свої RFC.
9
Це здається марним грубим і педантичним менш корисним способом. У прикладі PUT, який ви цитуєте, новий об'єкт RESTful api є «новим» записом і доступний в цьому місці. Не викликає сумнівів, чи є гарний вибір дизайну, що дозволяє підмінам бути такими, як це (я думаю, що це не ідеальний варіант), але навіть якби ви використовували підвид, щоб нападати на велику корисну інформацію. У більшості випадків опис, як зазвичай кажуть, є чудовою заявою про зміст RFC, підсумовану і заяву звичайної та звичайної практики. Крім того, вам не буде боляче бути чемним. - tooluser 06 квіт. 15 2015-04-06 23:49:56
60
1) GET: - Використовується, коли клієнт просить ресурс на веб-сервері.
2) HEAD: - Використовується, коли клієнт запитує деяку інформацію про ресурс, але не запитує сам ресурс.
3) POST: - Використовується, коли клієнт відправляє інформацію чи дані на сервер, наприклад, заповнюючи онлайн-форму (тобто. відправляє на веб-сервер дуже багато складних даних).
4) PUT: - Використовується, коли клієнт відправляє документ, що замінює, або завантажує новий документ на веб-сервер під URL-адресою запиту.
5) ВИДАЛИТИ: - Використовується, коли клієнт намагається видалити документ із веб-сервера, ідентифікований URL-адресою запиту.
6) TRACE: - Використовується, коли клієнт запитує доступні проксі або проміжні сервери, що змінюють запит, щоб оголосити себе.
7) ОПЦІЇ: - Використовується коли клієнт хоче визначити інші доступні методи для вилучення або обробки документа на веб-сервері.
8) CONNECT: - Використовується, коли клієнт хоче встановити прозоре з'єднання з віддаленим хостом, як правило, для забезпечення SSL-шифрованого зв'язку (HTTPS) через HTTP-проксі.
15
