Яка різниця між HTTP та REST?

Прочитавши багато про відмінності між REST та SOAP, у мене склалося враження, що REST - це ще одне слово для HTTP. Чи може хтось пояснити, яку функціональність REST додає до HTTP?

Примітка . Я не шукаю порівняння REST з SOAP.

Оновлення : Дякую за відповіді. Тепер мені стало зрозуміло, що REST - це лише набір правил щодо використання HTTP. Отже, я опублікував подальші дії щодо переваг цих конвенцій .

Примітка : тепер я розумію значення REST; як зазначає Еміль Іванов , REST означає використовувати HTTP таким, яким він мав бути. Однак я не впевнений, чи заслуговує це власний термін, і я, звичайно, не відчуваю галасу навколо цього.

Ні, REST шлях HTTP повинен бути використаний .

Сьогодні ми використовуємо лише невеликий біт методів протоколу HTTP - а саме GETі POST. REST спосіб зробити це - використовувати всі методи протоколу.

Наприклад, REST диктує використання DELETEстирання документа (будь то файл, стан тощо) за URI, тоді як з HTTP ви неправильно використовуєте a GETабо POSTзапит на зразок ...product/?delete_id=22.

HTTP - це протокол, який використовується для зв'язку, зазвичай використовується для спілкування з Інтернет-ресурсами або будь-якою програмою з клієнтом веб-браузера.

REST означає, що основною концепцією, яку ви використовуєте під час проектування програми, є Ресурс: для кожної дії, яку ви хочете виконати, потрібно визначити ресурс, на якому ви зазвичай виконуєте лише операцію CRUD, що є простим завданням. для цього дуже зручно використовувати 4 дієслова, які використовуються в протоколі HTTP проти 4 операцій CRUD (Get for Read, POST - для CREATE, PUT - для UPDATE, DELETE - для DELETE). це на відміну від старої концепції RPC (Remote Procedure Call), в якій у вас є набір дій, які ви хочете виконати в результаті виклику користувача. якщо ви думаєте, наприклад, про те, як описати фейсбук, як у публікації, за допомогою RPC ви можете створити сервіси під назвою AddLikeToPost та RemoveLikeFromPost, а також керувати ним разом із усіма іншими службами, пов’язаними з повідомленнями FB, тому вам не потрібно буде створювати спеціальні об’єкт для Like. з REST у вас з'явиться об’єкт Like, яким керуватимуть окремо за допомогою функцій Видалення та створення. Це також означає, що вона опише окрему сутність у вашому db. це може виглядати як невелика різниця, але така робота, як правило, дає набагато простіший код і набагато простіший додаток. при такому дизайні більша частина логіки програми очевидна із структури (моделі) об'єкта, на відміну від RPC, з яким зазвичай потрібно явно додати набагато більше логіки.

розробити додаток RESTful, як правило, набагато складніше, оскільки це вимагає, щоб ви описували складні речі просто. опис усіх функціональних можливостей, що використовують лише функції CRUD, є складним, але, зробивши це, ваше життя було б набагато простішим, і ви побачите, що будете писати набагато коротші методи.

Ще одна стримана архітектура REST - це не використовувати контекст сеансу під час спілкування з клієнтом (без громадянства), тобто вся інформація, необхідна для розуміння того, хто є клієнтом і що він хоче, передається разом із веб-повідомленням. кожен виклик функції є самоописовим, немає попередньої розмови з клієнтом, на яку можна посилатися в повідомленні. для цього клієнт не міг сказати вам "дайте мені наступну сторінку", оскільки у вас немає сеансу, щоб зберігати попередню сторінку та яку сторінку ви хочете, клієнт повинен сказати "мене звуть yuval, отримайте мені сторінка 2 певної публікації на певному форумі ". це означає, що трохи більше даних доведеться передати в комунікації, але подумайте про різницю між знаходженням помилки, повідомленої від функції "отримати мені наступну сторінку" на противагу "

Звичайно, це набагато більше, але на мою думку, це основні поняття в чайній ложці.

HTTP - протокол програми. REST - це набір правил, які при дотриманні дозволяють створити розподілений додаток, який має певний набір бажаних обмежень.

Якщо ви шукаєте найбільш значні обмеження REST, які відрізняють додаток RESTful від будь-якого додатку HTTP, я б сказав, обмеження "самоопису" та обмеження гіпермедіа (він же Hypermedia як двигун стану додатків (HATEOAS)) Найбільш важливим.

Обмеження для самоопису вимагає, щоб RESTful запит був повністю описовим у намірах користувачів. Це дозволяє посередникам (проксі та кешам) безпечно діяти на повідомленні.

Обмеження HATEOAS полягає у перетворенні вашої програми на мережу посилань, де поточний стан клієнта базується на його місці в цій мережі. Це хитра концепція і вимагає більше часу для пояснення, ніж у мене зараз.

Як я розумію, REST застосовує використання доступних команд HTTP так, як вони мали бути використані.

Наприклад, я можу зробити:

GET
http://example.com?method=delete&item=xxx

Але в спокої я б застосував метод "DELETE" запиту, усунувши необхідність у параметрі запиту "method"

DELETE
http://example.com?item=xxx

Не зовсім...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST спочатку описувався в контексті HTTP, але не обмежується цим протоколом. RESTful архітектури можуть базуватися на інших протоколах рівня додатків, якщо вони вже забезпечують багатий і однорідний словник для додатків на основі передачі значущого стану репрезентації. Програми RESTful дозволяють максимально використовувати наявний, чітко визначений інтерфейс та інші вбудовані можливості, передбачені вибраним мережевим протоколом, і мінімізувати додавання нових функцій, що стосуються додатків.

http://www.looselycoupled.com/glossary/SOAP

(Простий протокол доступу до об’єктів) Стандарт для повідомлень веб-служб. На основі XML SOAP визначає формат конверта та різні правила опису його вмісту. Вбачається (з WSDL та UDDI) як один із трьох базових стандартів веб-сервісів, це кращий протокол обміну веб-сервісами, але аж ніяк не єдиний; прихильники REST кажуть, що це додає зайвої складності.

REST - це специфічний спосіб підходу до проектування великих систем (наприклад, Інтернету).

Це набір "правил" (або "обмежень").

HTTP - це протокол, який намагається дотримуватися цих правил.

REST = Представницький державний трансфер

REST - це набір правил, які при дотриманні дозволяють створити розподілений додаток, який має певний набір бажаних обмежень.

REST - це протокол для обміну будь-якими (XML, JSON тощо) повідомленнями, які можуть використовувати HTTP для транспортування цих повідомлень.

Особливості:

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

Переваги безгромадянства:

1. Веб-сервіси можуть розглядати кожен виклик методу окремо.
2. Веб-сервіси не повинні підтримувати попередню взаємодію клієнта.
3. Це в свою чергу спрощує дизайн додатків.
4. HTTP сам по собі є протоколом без громадянства на відміну від TCP, і таким чином RESTful веб-сервіси безперебійно працюють з протоколами HTTP.

Недоліки безгромадянства:

1. До кожного запиту потрібно додати один додатковий шар у вигляді заголовка, щоб зберегти стан клієнта.
2. Для безпеки нам потрібно додати інформацію заголовка до кожного запиту.

Методи HTTP, які підтримує REST:

GET: / string / someotherstring Ідентичний, і в ідеалі повинен повертати однакові результати щоразу, коли виконується дзвінок

PUT: Те саме, що і GET. Idempotent і використовується для оновлення ресурсів.

POST: повинен містити URL-адресу та тіло, яке використовується для створення ресурсів. Кілька дзвінків в ідеалі повинні повертати різні результати та створювати декілька продуктів.

DELETE: використовується для видалення ресурсів на сервері.

ГОЛОВА:

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

ВАРІАНТИ:

Цей метод дозволяє клієнту визначати параметри та / або вимоги, пов'язані з ресурсом, або можливостями сервера, не передбачаючи дії з ресурсом або ініціюючи пошук ресурсу.

HTTP-відповіді

Перейдіть сюди за всіма відповідями .

Ось кілька важливих: 200 - OK 3XX - Додаткова інформація, необхідна клієнту та переадресація URL-адреси 400 - Неправильний запит
401 - Несанкціонований доступ
403 - Заборонено
Запит був дійсним, але сервер відмовляється від дії. Користувач може не мати необхідних дозволів на ресурс або може знадобитися якийсь обліковий запис.

404 - Не знайдено
Запрошений ресурс не вдалося знайти, але він може бути доступний у майбутньому. Подальші запити клієнта допустимі.

405 - Метод не дозволений Метод запиту не підтримується для запитуваного ресурсу; наприклад, запит GET у формі, яка вимагає подання даних через POST, або запит PUT на ресурсі лише для читання.

404 - Запит не знайдено
500 - Внутрішня
помилка сервера 502 - Помилка поганого шлюзу

HTTP - протокол зв’язку, який переносить повідомлення по мережі. SOAP - це протокол для обміну повідомленнями на основі XML, які можуть використовувати HTTP для транспортування цих повідомлень. Відпочинок - це протокол для обміну будь-якими (XML або JSON) повідомленнями, які можуть використовувати HTTP для транспортування цих повідомлень.

HTTP is a contract, a communication protocol and REST is a concept, an architectural style який може використовувати протокол HTTP, FTP або інші протоколи зв'язку, але широко використовується з HTTP.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer, він найчастіше використовується в API REST лише тому, що REST was inspired by WWW (world wide web) which largely used HTTPдо того, як було визначено REST, тому простіше реалізувати стиль REST API за допомогою HTTP.

There are three major constraints in REST (but there are more):

1. Взаємодія між сервером і клієнтом повинна описуватися лише через гіпертекст.

2.Сервер і клієнт повинні бути вільно пов'язані між собою і не робити припущень один про одного. Клієнт повинен знати лише точку введення ресурсу. Дані про взаємодію повинні бути надані сервером у відповідь.

3.Сервер не повинен зберігати інформацію про контекст запиту. Запити повинні бути незалежними та ідентичними (тобто, якщо той самий запит повторюється нескінченно, отримується точно такий же результат)

І HTTP - це просто протокол зв'язку (інструмент), який може допомогти досягти цього.

Для отримання додаткової інформації перевірте ці посилання:

https://martinfowler.com/articles/richardsonMaturanceModel.html http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

REST не обов'язково прив’язаний до HTTP . RESTful веб-сервіси - це лише веб-сервіси, які відповідають архітектурі RESTful.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface

Звідки ви не знаєте різниці між HTTP та REST

Тож архітектура REST та протокол HTTP 1.1 не залежать одна від одної, але протокол HTTP 1.1 був побудований для ідеального протоколу для дотримання принципів та обмежень REST. Один із способів подивитися на зв'язок між HTTP та REST - це те, що REST - це дизайн, а HTTP 1.1 - це реалізація цієї конструкції.

API REST має керуватися гіпертекстом

У блозі Роя Філдінга ви знайдете набір способів перевірити, чи ви створюєте HTTP API чи REST API:

Дизайнери API, будь ласка, врахуйте наступні правила, перш ніж називати ваше створення REST API:

• API REST не повинен залежати від будь-якого єдиного протоколу зв'язку, хоча його успішне відображення на даний протокол може залежати від наявності метаданих, вибору методів тощо. Загалом, будь-який елемент протоколу, який використовує URI для ідентифікації, повинен дозволити будь-яка схема URI, яка повинна використовуватись для цієї ідентифікації. [Невдача тут означає, що ідентифікація не відокремлена від взаємодії.]
• API REST не повинен містити жодних змін у протоколах зв’язку, крім заповнення або фіксації деталей недоозначених бітів стандартних протоколів, таких як метод PATCH HTTP або поле заголовка посилання. Обхідні шляхи для зламаних реалізацій (наприклад, у тих браузерах, які досить дурні, щоб вважати, що HTML визначає набір методів HTTP) слід визначати окремо або, принаймні, у додатках, з надією, що врешті-решт врегулювання застаріло застарілим. [Невдача тут означає, що інтерфейси ресурсів є об'єктними, а не загальними.]
• API REST повинен витратити майже всі свої описові зусилля на визначення типів медіа (ів), які використовуються для представлення ресурсів та керування станом програми, або для визначення розширених імен відношень та / або розмітки з підтримкою гіпертексту для існуючих стандартних типів медіа. Будь-які зусилля, витрачені на опис того, які методи використовувати для цікавих URI, повинні бути повністю визначені в межах правил обробки для медіа-типу (і, в більшості випадків, вже визначені існуючими типами медіа). [Невдача тут означає, що інформація про позадіапазон є рушійною взаємодією замість гіпертексту.]
• API REST не повинен визначати імена фіксованих ресурсів або ієрархії (очевидно з'єднання клієнта і сервера). Сервери повинні мати свободу контролювати власний простір імен. Натомість, дозвольте серверам вказувати клієнтам, як створити відповідні URI, такі як це робиться у формах HTML та шаблонах URI, шляхом визначення цих інструкцій у межах типів медіа та зв’язків зв’язків. [Відмова тут означає, що клієнти приймають структуру ресурсів через позадіапазонну інформацію, таку як доменний стандарт, який орієнтований на дані, еквівалентний функціональному зв'язку RPC].
• API REST ніколи не повинен мати «типізовані» ресурси, які є важливими для клієнта. Автори специфікацій можуть використовувати типи ресурсів для опису реалізації сервера за інтерфейсом, але ці типи повинні бути неактуальними та невидимими для клієнта. Єдині типи, які є важливими для клієнта, - це тип медіа-даних поточного представлення та стандартизовані назви відносин. [ditto]
• API REST слід вводити без попередніх знань понад початковий URI (закладку) та набір стандартизованих типів носіїв, які підходять для призначеної аудиторії (тобто очікується, що їх зрозуміє будь-який клієнт, який може використовувати API). З цього моменту всі переходи стану додатків повинні керуватися вибором клієнта вибору, наданого сервером, який присутній в отриманих представленнях або мається на увазі шляхом маніпулювання користувачем цими представленнями. Переходи можуть визначатися (або обмежуватися) знаннями клієнта про типи засобів масової інформації та механізми комунікації з ресурсами, обидва вони можуть бути вдосконалені на ходу (наприклад, код за запитом). [Невдача тут означає, що інформація про позадіапазон є рушійною взаємодією замість гіпертексту.]