Що таке REST? Трохи розгублений [закрито]

Я був припущений, що REST - це веб-сервіс, але, здається, я неправильно вважаю це - так, що таке REST?

Я читав у Вікіпедії, але все ще не можу обернути голову навколо цього. Чому багато місць називають API API REST API?

REST - це не конкретна веб-служба, а концепція дизайну (архітектура) для управління державною інформацією. Навчальний документ про це - дисертація Роя Томаса Філдінга (2000) "Архітектурні стилі та дизайн мережевих програмних архітектур" ( доступна в Інтернеті від Каліфорнійського університету, Ірвайн).

Вперше прочитав пост Райана Томайко Як я пояснив REST дружині ; це відмінна відправна точка. Потім прочитайте фактичну дисертацію Філдінга. Це не так вже й просунуто, а також не довго (шість глав, 180 сторінок)! (Я знаю, ви, діти, в школі люблять це коротко).

EDIT: Я вважаю, що безглуздо намагатися пояснити REST. У ньому є стільки таких понять, як масштабованість, наочність (без громадянства) тощо, що читачеві потрібно зрозуміти, а найкращим джерелом для їх розуміння є власне дисертація. Це набагато більше, ніж POST / GET і т.д.

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

Найбільш основний спосіб мислення про REST - це спосіб форматування URL-адрес ваших веб-додатків. Наприклад, якщо ваш ресурс називався "повідомленнями", то:

/posts Як користувач отримав би доступ до ВСІХ публікацій для їх відображення.

/posts/:id Як користувач отримав би доступ та переглянув окрему публікацію, отриману на основі свого унікального ідентифікатора.

/posts/new Як би ви відображали форму для створення нової публікації.

Надіслати запит на POST /usersбуде таким чином, як ви насправді створили б новий пост на рівні бази даних.

Надіслати запит PUT до /users/:idтого, як ви оновите атрибути даної публікації, знову ж таки ідентифіковані унікальним ідентифікатором.

Надіслати DELETE-запит /users/:idбуде таким чином, як ви видалите дану публікацію, знову визначену унікальним ідентифікатором.

Як я розумію, модель REST в основному популяризувалася (для веб-додатків) рамкою Ruby on Rails, яка робить великий акцент на маршрутах RESTful. Я можу помилитися з цього приводу.

Я, можливо, не найбільш кваліфікований, щоб про це говорити, але саме так я це дізнався (спеціально для розвитку Rails).

Коли хтось посилається на "REST api", загалом те, що вони означають, є api, який використовує RESTful URL-адреси для отримання даних.

RESTє архітектурним стилем та дизайном для мережевих програмних архітектур.

RESTПоняття називають ресурсами. Представлення ресурсу повинно бути без громадянства. Він представлений через певний тип носія. Деякі приклади типів носіїв включають в себе XML, JSONі RDF. Ресурсами маніпулюють компоненти. Компоненти запитують та маніпулюють ресурсами через стандартний єдиний інтерфейс. У разі HTTP, цей інтерфейс складається з стандартної HTTP опса наприклад GET, PUT, POST, DELETE.

RESTЗазвичай використовується в HTTPосновному через простоту HTTP та його дуже природне відображення на принципи RESTful. Однак REST не прив’язаний до жодного конкретного протоколу.

Основні принципи REST

Зв'язок клієнт-сервер

Архітектура клієнт-сервер має дуже чітке розділення проблем. Усі програми, побудовані у стилі RESTful, також повинні бути принципово клієнт-сервер.

Без громадянства

Кожен запит клієнта до сервера вимагає повного представлення його стану. Сервер повинен бути в змозі повністю зрозуміти запит клієнта без використання будь-якого контексту сервера або стану сеансу сервера. Звідси випливає, що весь стан повинен зберігатися у клієнта. Ми розглянемо представництво без громадянства детальніше пізніше.

Кешований

Обмеження кеш-пам'яті можуть бути використані, таким чином дозволяючи позначати дані відповіді як кешовані або не кешовані. Будь-які дані, позначені як кешовані, можуть бути повторно використані як відповідь на той же наступний запит.

Уніфікований інтерфейс

Усі компоненти повинні взаємодіяти через єдиний єдиний інтерфейс. Оскільки взаємодія всіх компонентів відбувається через цей інтерфейс, взаємодія з різними службами дуже проста. Інтерфейс той самий! Це також означає, що зміни в реалізації можуть бути здійснені поодиноко. Такі зміни не вплинуть на взаємодію основних компонентів, оскільки єдиний інтерфейс завжди не змінюється. Одним недоліком є ​​те, що ви застрягли в інтерфейсі. Якщо оптимізація може бути надана певній службі шляхом зміни інтерфейсу, вам не пощастило, оскільки REST забороняє це. З іншого боку, REST оптимізовано для Інтернету, отже, неймовірна популярність REST через HTTP!

Вищезазначені поняття представляють визначальні характеристики REST та відрізняють архітектуру REST від інших архітектур, таких як веб-сервіси. Корисно зауважити, що послуга REST - це веб-служба, але веб-служба не обов'язково є послугою REST.

Дивіться цю публікацію в блозі про принципи дизайну REST для отримання більш детальної інформації про REST та вищезазначені принципи.

Це означає «Представницький державний трансфер», і це може означати багато чого, але зазвичай, коли ви говорите про API та додатки, ви говорите про REST як про спосіб робити веб-сервіси або отримувати програми для спілкування через Інтернет.

REST - це в основному спосіб спілкування між системами і робить багато з того, що було розроблено для SOAP RPC, але, хоча SOAP, як правило, здійснює з'єднання, аутентифікується, а потім виконує роботу над цим з'єднанням, REST працює майже так само, як і в Інтернеті . У вас є URL-адреса, і коли ви запитуєте цю URL-адресу, ви отримуєте щось назад. Тут дещо стає заплутаним, оскільки люди описують Інтернет як найбільший додаток REST, і хоча це технічно правильно, воно насправді не допомагає пояснити, що це таке.

Коротше кажучи, REST дозволяє вам отримати два програми, що розмовляють через Інтернет, використовуючи інструменти, подібні до того, який використовує веб-браузер. Це набагато простіше, ніж SOAP, і багато з того, що робить REST, говорить: "Ей, речі не повинні бути такими складними".

Варто прочитати:

• Як я пояснив REST своїй дружині (зараз доступний тут)
• Архітектурні стилі та дизайн мережевих архітектур програмного забезпечення

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

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