Питання Що саме RESTful програмування?


Що саме RESTful програмування?


3630
2018-03-22 14:45


походження


дивіться також відповідь на наступну посилання stackoverflow.com/a/37683965/3762855 - Ciro Corvino
REST може стати трохи застарілим зараз;) youtu.be/WQLzZf34FJ8 - Vlady Veselinov
Також, перейдіть за цим посиланням, щоб отримати додаткову інформацію news.ycombinator.com/item?id=3538585 - Ashraf.Shk786
Поправки до прийнятої відповіді тут. stackoverflow.com/questions/19843480/...  Або тут roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  Або тут web.archive.org/web/20130116005443/http://tomayko.com/writings/... - kushalvm
@ OLIVER.KOO приємного спостереження. Це якраз те, що я запитав його в той час, коли це була якась нова річ. Це було дуже багато, але мало хто знав, що це таке. Принаймні, я цього не зробив, і мені здається, що це допомогло їм, бо вони теж хотіли знати. - hasen


Відповіді:


Ан архітектурний стиль називається REST (репрезентативний державний трансфер) виступає за те, що веб-додатки повинні використовувати HTTP, як було спочатку передбачалося. Шукачі слід використовувати GET запити PUT, POST, і DELETE запити слід використовувати для мутація, створення та видалення відповідно.

Прихильники REST, як правило, надають перевагу URL-адресам, таким як

http://myserver.com/catalog/item/1729

але архітектура REST не вимагає цих "досить URL-адрес". Запит GET з параметром

http://myserver.com/catalog?item=1729

це як би RESTful.

Пам'ятайте, що запити GET ніколи не повинні використовуватися для оновлення інформації. Наприклад, запит GET для додавання елемента в кошик

http://myserver.com/addToCart?cart=314159&item=1729

не буде доречним. GET запити повинні бути ідемпотент. Тобто, подання запиту двічі не повинно нічим відрізнятися від видачі його один раз. Це робить кешування запитів. Запит "додати до кошика" не є ідемпотенційним, його двічі додає дві копії елемента до кошика. Запит POST явно доречний у цьому контексті. Таким чином, навіть а RESTful веб-додаток потребує свою частку запитів POST.

Це взято з чудової книги Ядро JavaServer обличчя книга Девіда М. Гері.


541
2018-04-15 11:26



Додавання доступних ідемопотенційних операцій: GET (Безпечний), PUT & DELETE (Виняток згадується в цьому посиланні restapitutorial.com/lessons/idempotency.html). Додаткова довідка для безпечних та ідентипотівних методів w3.org/Protocols/rfc2616/rfc2616-sec9.html - Abhijeet
а) важливим пунктом про GET є безпечність, а не ідемопотуса; б) @Abhijeet: RFC 2616 був занедбаний у 2014 році; див RF 7230ff. - Julian Reschke
Це неправильно. Прочитайте це для правильної інтерпретації REST roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven  або це stackoverflow.com/questions/19843480/... - kushalvm
@kushalvm Те академічне визначення REST не використовується на практиці. - Elliott Beach
REST ніколи не був призначений для використання в веб-інтерфейсах API, тільки для статичних ресурсів, і вони є гіпертекстовий. Проте Філдінг, у всій своїй науковій наївності, вважав, що вони будуть підтримуватися за допомогою всіх цих HTTP-дієслів безпосередньо з браузера, що не є практичним ні в якому разі. REST - це не що інше, як купа безглуздих бузкових слів, і її треба відмовитися як можна швидше. - Vadim Ferderer


Відпочинок є основним архітектурним принципом Інтернету. Дивовижна справа в Інтернеті полягає в тому, що клієнти (браузери) та сервери можуть взаємодіяти складно, без того, щоб клієнт нічого не знав про це раніше про сервер та ресурси, на яких він розміщений. Ключовим обмеженням є те, що сервер і клієнт повинні як погодитися на ЗМІ використовується, що у випадку з Інтернетом HTML.

API, який дотримується принципів Відпочинок не вимагає від клієнта нічого знати про структуру API. Натомість сервер повинен надати будь-яку інформацію, яку клієнт повинен взаємодіяти з послугою. Ан HTML форма є прикладом цього: сервер вказує розташування ресурсу та необхідні поля. Браузер не знає заздалегідь, де подати інформацію, і не знає заздалегідь, яку інформацію надати. Обидві форми інформації повністю поставляються сервером. (Цей принцип називається HATEOAS: Гіпермедіа як двигун стану застосування.)

Отже, як це стосується HTTP, і як це можна реалізувати на практиці? HTTP орієнтована на дієслова та ресурси. Два дієслова в основному використовують GET і POST, які, я думаю, всі розпізнають. Однак стандарт HTTP визначає кілька інших, таких як PUT і DELETE. Ці дієслова потім застосовуються до ресурсів відповідно до інструкцій, наданих сервером.

Наприклад, давайте припустимо, що ми маємо користувацьку базу даних, яка управляється веб-службою. Наш сервіс використовує спеціальну гіпермедіа на основі JSON, для якої ми призначаємо mimetype application / json + userdb (Там також може бути application / xml + userdb і application / whatever + userdb - може підтримуватися багато типів носіїв). Клієнт і сервер обидва були запрограмовані на розуміння цього формату, але вони нічого не знають про один одного. Як Рой Філдінг вказує на те:

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

Запит на базовий ресурс / може повернутись приблизно так:

Запит

GET /
Accept: application/json+userdb

Відповідь

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

З нашого засобу масової інформації ми знаємо, що ми можемо знайти інформацію про відповідні ресурси з розділів під назвою "посилання". Це називається Гіпермедіа контролює. У цьому випадку з такого розділу ми можемо сказати, що ми можемо знайти список користувачів, зробивши ще один запит /user:

Запит

GET /user
Accept: application/json+userdb

Відповідь

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Ми можемо багато чого сказати з цієї відповіді. Наприклад, тепер ми знаємо, що ми можемо створити нового користувача, використовуючи POSTing to /user:

Запит

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Відповідь

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Ми також знаємо, що ми можемо змінювати існуючі дані:

Запит

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Відповідь

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Зверніть увагу, що ми використовуємо різні дієслова HTTP (GET, PUT, POST, DELETE тощо), щоб маніпулювати цими ресурсами, і що єдиним знанням, яке ми вважаємо клієнтом, є наше визначення мультимедіа.

Подальше читання:

(Ця відповідь є предметом справедливої ​​критики про відсутність цього пункту. Здебільшого це було справедливою критикою. Те, що я спочатку описував, більше відповідає тому, як РЕСТ, як правило, було реалізовано кілька років тому, коли я Спочатку це написано, а не його справжнє значення. Я переглянув відповідь, щоб краще представляти справжнє значення.)


2788
2018-03-22 19:37



Ні. РЕСТ не просто спливав як інше слово. Це сталося як засіб опису альтернативи обміну даними на базі SOAP. Термін "REST" допомагає формувати дискусію про те, як передавати та отримувати доступ до даних. - tvanfosson
Тим не менш, серце REST (в практичному застосуванні) полягає в тому, що "не використовуйте GET для внесення змін, використовуйте POST / PUT / DELETE", це порада, яку я чую (і слідкуючи) задовго до появи SOAP. Відпочинок мав завжди був там, він просто не отримав назви за "спосіб зробити це" до недавнього часу. - Dave Sherohman
Не забудьте "гіпертекст як двигун програми застосування". - Hank Gay
Ця відповідь не підходить. HTTP навряд чи згадується в дисертації Філдінга. - user359996
Ця відповідь не згадує про мету REST, і це здається, це все, що стосується чистих URI. Хоча це може бути популярним сприйняттям REST, відповіді Д. Шоулі та логіни - більш точні - це вміння скористатися функціями, вбудованими в архітектуру, такими як кешування, працюючи з ним, а не проти нього. Більш чутливі URI є переважно поширеним побічним ефектом. - T.R.


RESTful програмування про:

  • ресурси ідентифікуються постійним ідентифікатором: URI - повсюдний вибір ідентифікатора в ці дні
  • ресурси маніпулюються з використанням спільного набору дієслів: методи HTTP є загальноприйнятою справою - поважний Create, Retrieve, Update, Delete стає POST, GET, PUT, і DELETE. Але REST не обмежується HTTP, це просто найпопулярніший транспорт зараз.
  • фактичне представлення, отримане для ресурсу, залежить від запиту, а не від ідентифікатора: використовуйте заголовки Accept, щоб визначити, чи хочете ви XML, HTTP чи навіть об'єкт Java, що представляє ресурс
  • підтримка держави в об'єкті та представлення держави у представленні
  • що відображають взаємозв'язок між ресурсами у представленні ресурсу: зв'язки між об'єктами вбудовуються безпосередньо в представлення
  • Представлення ресурсів описує, як представлення може бути використане, і за яких обставин воно має бути відкинуто / повторно відновлено послідовно: використання заголовків HTTP Cache-Control

Останній, мабуть, найбільш важливий з точки зору наслідків та загальної ефективності REST. В цілому, більшість дискусій REST, схоже, зосереджуються на HTTP і його використанні в браузері, а що ні. Я розумію, що Р. Філдінг створив термін, коли він описав архітектуру та рішення, що призводять до HTTP. Його дисертація більше про архітектуру та кеш-пам'ять ресурсів, ніж про HTTP.

Якщо ви дійсно зацікавлені в тому, яка архітектура RESTful і чому вона працює, прочитайте його теза кілька разів і читай все це не просто глава 5! Далі розгляньмо чому DNS працює. Прочитайте про ієрархічну організацію DNS і про те, як працюють реферали. Потім прочитайте та розгляньте, як працює кеш DNS. Нарешті, прочитайте специфікації HTTP (RFC2616 і RFC3040 зокрема) та розглянути, як і чому кешування працює так, як це робиться. Зрештою, він просто натисне. Останнє одкровення для мене було, коли я побачив подібність між DNS і HTTP. Після цього зрозуміло, чому SOA та Message Passing Interfaces масштабні, починає натискати.

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


500
2017-07-04 05:47



Відповідь, що надає список читання, дуже підходить для цього питання. - ellisbben
Дякуємо за оновлення. PUT і POST насправді взагалі не інформується один з одним про оновлення та створення. PUT може бути використаний для створення, якщо клієнт диктує, що таке URI. POST створює, якщо сервер призначає новий URI. - D.Shawley
Не забувайте PATCH. - epitka
URN - це URI, який використовує urn: схема Концептуально немає різниці; однак, URN вимагає наявності окремо визначеного методу, щоб "знайти" ресурс, ідентифікований (названий) URN. Необхідно уважно стежити за тим, щоб ви не запроваджували неявне сполучення, коли пов'язано з названими ресурсами та їх розташуванням. - D.Shawley
@elisbben згоден Якщо я правильно розумію, це дисертація, яка породила РЕСТ: ics.uci.edu/ ~fielding/pubs/dissertation/rest_arch_style.htm - Philip Couling


Ось що може виглядати.

Створіть користувача з трьома властивостями:

POST /user
fname=John&lname=Doe&age=25

Сервер відповідає:

200 OK
Location: /user/123

В майбутньому ви зможете отримати інформацію про користувача:

GET /user/123

Сервер відповідає:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Змінити запис (lname і age залишиться незмінним):

PATCH /user/123
fname=Johnny

Оновити запис (і, відповідно, lname і age буде NULL):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Для мене ця відповідь відобразила суть бажаної відповіді. Простий і прагматичний. Отримано безліч інших критеріїв, але наведений приклад - прекрасна стартова майданчик. - CyberFonic
У останньому прикладі @pbreitenbach використовує PUT fname=Jonny. Це буде встановлено lname і age до значень за замовчуванням (мабуть, NULL або порожня рядок та ціле число 0), тому що a PUT  перезаписує весь ресурс з даними представленого представлення. Це не те, що мається на увазі під час оновлення зробити справжнє оновлення, скористайтеся PATCH метод оскільки це не змінює поля, які не вказані у поданні. - Nicholas Shanks
Микола прав. Крім того, URI для першого POST, що створює користувача, слід називати користувачами через /user/1 не має ніякого сенсу, і там повинен бути список на /users. Відповідь повинна бути a 201 Created і не просто добре в такому випадку. - DanMan
Микола та Данман правильні. Ця відповідь є стислою, але має кілька недоліків. - leslie.zhang
Це лише приклад API, який не обов'язково є RESTful api. RESTful має обмеження, до яких він дотримується. Архітектура клієнт-сервер, Безпатентність, кеш-пам'ять, Layered System, Єдиний інтерфейс. - Radmation


Прекрасна книга на REST REST на практиці.

Треба читати Представницький державний трансфер (REST) і API REST має бути гіпертекстовим 

Див. Мартін Фауллер, статті Модель Річардсона зрілості (RMM) для пояснення того, яка служба RESTful.

Richardson Maturity Model

Для того, щоб бути ВІДТВОРЕНОМ, Сервіс повинен виконати Hypermedia як двигун додатків держави. (HATEOAS), тобто він повинен досягти рівня 3 у РМЗ, прочитати статтю для подробиць або слайди з qcon розмови.

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

...

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

REST Лакмусовий тест для веб-рамок аналогічний тест на зрілість для веб-структур.

Наближення чистого РЕСТУ: Навчання любити HATEOAS це хороша колекція посилань.

REST проти SOAP для Public Cloud обговорює поточні рівні використання REST.

REST та версію обговорюється розширюваність, версія, еволюційність та ін  через модифікованість


170
2018-03-22 15:20



Я думаю, що ця відповідь стосується ключової точки розуміння РЕСТ: що таке слово репрезентативний означає Рівень 1 - Про ресурси держава. Рівень 2 - Дієслова HTTP говорить про передача (читай змінити) Рівень 3 - HATEOAS говорить про те, що майбутні перекази здійснюються через представництво (JSON / XML / HTML повернуто), що означає, що ви знали, як сказати наступний раунд розмови з повернутою інформацією. Отже, REST читає: "(репрезентативний (передача держави)"), а не "((репрезентативний стан) передача") ". - lcn
Різниця між REST та POX - nobar


Що таке РЕСТ?

REST означає Representational State Transfer. (Це іноді   написано "ReST".) Вона спирається на бездержавний, клієнт-сервер, кешуваний   протокол зв'язку - і практично у всіх випадках HTTP   протокол використовується.

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

Багато в чому, сама Всесвітня Веб-Веб, заснована на HTTP, може бути переглянута   як архітектура на базі REST. REST-програми використовують HTTP-запити   публікувати дані (створювати та / або оновлювати), читати дані (наприклад, створювати запити),   і видалити дані. Таким чином, REST використовує HTTP для всіх чотирьох CRUD   (Створення / читання / оновлення / видалення).

REST є легкою альтернативою таким механізмам, як RPC (Remote   Процедура викликів) та веб-служб (SOAP, WSDL та ін.). Пізніше ми будемо   Подивіться, наскільки більш простий РЕСТ.

Незважаючи на те, що простий, REST є повнофункціональним; там в основному   Ви нічого не можете робити в веб-службах, які неможливо виконати за допомогою RESTful   архітектура. REST не є "стандартним". Там ніколи не буде W3C   Наприклад, рекомендований для REST. І хоча Є РЕСТ   програмування, робота з REST настільки проста, що ви можете   часто "рухайся своїми" зі стандартними функціями бібліотеки в таких мовах   Perl, Java або C #.

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

http://rest.elkstein.org/


128
2018-03-22 14:53





REST використовує різні HTTP-методи (переважно GET / PUT / DELETE) для обробки даних.

Замість того, щоб використовувати певну URL-адресу, щоб видалити метод (скажімо, /user/123/delete), ви надішлете запит DELETE до /user/[id] URL, щоб редагувати користувача, щоб отримати інформацію про користувача, якому ви надсилаєте запит GET на /user/[id]

Наприклад, замість набору URL-адрес, які можуть виглядати як деякі з наступних.

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Ви використовуєте "дієслова" HTTP і маєте ..

GET /user/2
DELETE /user/2
PUT /user

85
2017-07-12 16:33



Це "правильно використовує HTTP", що не є таким самим, як "спокійний" (хоча це пов'язано з ним) - Julian Reschke
Ви також можете використовувати / user / del / 2 і / user / remove / 2 або ... GET / DELETE / PUT / POST - це просто стандартний "правильний" спосіб зробити такі речі (і, як каже Джуліан, це ще не все там ПОВИНЕН) - dbr
Звичайно, але це не є підставою для того, щоб уникнути їх. ПОВЕРНЕННЯ просто заощаджує вас від винаходу колеса кожен раз. Для API, REST чудово (послідовність!), Але для структурування випадкового веб-сайту це не має значення, я б сказав (це може бути більше клопоту, ніж це коштує) - dbr
Вадим, це буде просто RPC. Також небезпечно використовувати GET для зміни даних, оскільки (серед інших причин) пошукова система може спіймати ваші посилання для видалення та відвідати їх усі. - aehlke
@Aehlke - Я думаю, що справжнє питання буде "Чому анонімний користувач має можливість видаляти записи з вашої системи?" - Spencer Ruport