Навіщо нам потрібні RESTful веб-сервіси?

Я збираюся вивчити RESTful веб-сервіси (краще сказати, що мені доведеться це робити, тому що це частина програми магістерської програми CS).

Я прочитав деяку інформацію у Вікіпедії, а також прочитав статтю про REST в Sun Developer Network і бачу, що це непроста технологія, існують спеціальні рамки для побудови програм RESTful, і це часто порівнюється з веб-сервісами SOAP і програміст повинен розуміти, коли використовувати SOAP і коли REST може бути приємним підходом.

Я пам’ятаю, що кілька років тому SOAP був дуже популярним (модно?), А пункт «SOAP» повинен був бути присутнім у кожному хорошому резюме. Але на практиці його застосовували дуже рідко і для досягнення дуже простих цілей.

Мені здається, що REST - це ще одне «останнє слово моди» (або я можу абсолютно помилятися, тому що я ніколи не бачив REST на практиці).

Чи можете ви надати мені кілька прикладів: REST слід використовувати і чому ми не можемо зробити те ж саме без REST (або чому ми повинні витратити набагато більше часу, щоб зробити те ж саме без REST)?

UPD : На жаль, я не бачу жодних конкретних аргументів, які можуть забити мій погляд у перших коментарях. Змусити мене думати, що REST - це приголомшлива технологія!

Я хотів би побачити такі відповіді:

Я розробляв ще одне складне додаток HelloWorld, і нам потрібно передати багато / крихітних даних, і я запропонував REST рішення своєму колезі:

- О, чорт! Джоні, ми, звичайно, повинні використовувати REST для реалізації цього додатка!
- Так, Біллі, ми можемо використовувати REST, але краще використовувати SOAP. Повірте мені, бо я знаю щось про розробку програм HelloWorld.
- Але SOAP - це старомодна технологія минулого століття, і ми можемо використовувати кращу.
- Біллі, ти готовий витратити 3 дні на експерименти з REST? Ми можемо це зробити за допомогою SOAP за 2 години ..
- Так, я впевнений, що ми витратили ще більше часу на досягнення такої ж безпеки / продуктивності / / масштабованості / що б там не було ще з SOAP. Я впевнений, що програми HelloWorld відтепер повинні розроблятися лише з REST.

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

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

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

Адаптація насиченої поведінки сервера в єдиний інтерфейс HTTP може бути заплутаною і часом здається педантичною порівняно з порівняно простим підходом RPC.

Незважаючи на труднощі, переваги полягають у тому, що у вас є послуга, яку розробник клієнта повинен мати можливість легко зрозуміти через послідовне використання протоколу HTTP. Послуга має бути легко відкритою через гіпермедіа, і клієнт повинен бути надзвичайно стійким до змін на сервері .

Переваги гіпермедіа та уникнення стану сеансу робить балансування навантажень простим, а службовий розподіл можливим . Суворе відповідність HTTP правилам робить доступність таких інструментів, як налагоджувачі та кешування проксі-серверів.

Оновлення

Мені здається, що REST - це ще одне «останнє слово моди» (або я можу абсолютно помилятися, тому що я ніколи не бачив REST на практиці).

Я думаю, що REST став модним, тому що люди, що намагаються робити проекти типу SOA, виявили, що використовуючи стек SOAP, вони не реалізують обіцяних переваг. Люди постійно повертаються до Інтернету як приклад простих методологій інтеграції. На жаль, я вважаю, що люди недооцінюють обсяг планування та передбачуваності, який був розроблений в Інтернеті, і вони надмірно спрощують, що потрібно зробити, щоб дозволити багаторазове використання, яке відбувається в Інтернеті.

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

• Чому вам не потрібно оновлювати браузер, коли хтось змінює якийсь html на веб-сайті?
• Чому я можу додати повний новий набір сторінок на веб-сайт, і "клієнт" все ще може отримати доступ до цих нових сторінок без оновлення?
• Чому мені не потрібно надавати веб-браузеру "мову-опис служби", щоб сказати, коли мова йде про http://example.org/images/cat, що тип повернення буде зображенням jpeg та коли ви переходите для http://example.org/description/cat тип повернення буде text / html?
• Чому я можу використовувати веб-браузер для відвідування сайтів, які не існували після виходу браузера? Як клієнт може знати про ці сайти?

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

StackOverflow використовує різні сервіси OpenId для аутентифікації, gravatar.com для зображень аватарів, google-analytics та Quantserve для аналітичної інформації. Така різнорівнева інтеграція компаній є типом речі, про який мріє світ SOAP . Одним з найкращих прикладів є той факт, що бібліотеки jQuery, які використовуються для керування інтерфейсом StackOverflow, отримують із мережі доставки вмісту Google. Те, що SO може направити клієнта (тобто вашого веб-браузера) на завантаження коду з сторонніх сайтів для підвищення продуктивності, свідчить про низьку зв’язок між веб-клієнтом та сервером.

Це приклади архітектури REST на роботі.

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

• Сумнівна проблема з кнопкою повернення викликана використанням стану сеансу на стороні сервера.
• Балансування навантаження може стати болем, коли у вас є стан сеансу на стороні сервера.
• Флеш-програми часто заважають URL-адресу конкретно ідентифікувати представлення.
• Інша проблема, яка порушує веб-браузери - це погана відповідність стандартам медіа-типу. Ми постійно чуємо про те, як потрібно вбити IE6. Проблема полягає в тому, що стандарти не дотримувалися належним чином або були ігноровані з будь-якої причини.
• Використання сеансів входу є джерелом багатьох пробілів у безпеці.

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

Наскільки мені відомо, REST розпочав роботу дисертацією Роя Філдінга « Архітектурні стилі та дизайн мережевих програмних архітектур» , яку варто прочитати, якщо ви її ще не вивчали.

Вгорі дисертації - цитата:

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

- Крістофер Олександр, Невічний шлях будівництва (1979)

І це дійсно підсумовує це там. REST багато в чому елегантніший.

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

Від сюди :

Переваги:

• Легка вага - не багато зайвої розмітки в Xml
• Результати, зрозумілі для людини
• Простота в побудові - не потрібні набори інструментів

Також перевірте це :

Для справедливості, REST - не найкраще рішення для кожної веб-служби. Дані, які потрібно захистити, не повинні надсилатися як параметри в URI. А велика кількість даних, як, наприклад, у детальних замовленнях на купівлю, може швидко стати громіздкою або навіть вийти за межі в межах URI. У цих випадках SOAP дійсно є надійним рішенням. Але важливо спробувати REST спершу і вдатися до SOAP лише при необхідності. Це допомагає забезпечити просту та доступну розробку додатків.

Я з упевненістю можу сказати, що я витратив багато часу, щоб зрозуміти це як початківець, але це найкраще посилання для початку з REST з нуля! http://www.codeproject.com/Articles/21174/Everything- About-REST-Web-Services-What-and-How-Pa

Просто щоб затягнути вас,

Подумайте, що таке "традиційний веб-сервіс". Це інтерфейс з відкритими "методами". Клієнти знають ім'я методів, введення та виведення методів, а тому можуть викликати їх.

Тепер уявіть собі інтерфейс, який не піддається "методам". Натомість він викриває "предмети". Отже, коли клієнт бачить цей інтерфейс, все, що він бачить, - це один або кілька «об’єктів». "Об'єкт" не має вводу та виводу - тому що "він нічого не робить". Це іменник, а не дієслово. Це "річ", а не "дія".

Наприклад, подумайте про традиційний веб-сервіс, який надає поточні погодні умови, якщо ви надаєте йому місто. Ймовірно, є веб-метод на кшталт GetWeatherInfo (), який приймає місто як вхідний дані та надає дані про погоду як вихід. Поки вам легко зрозуміти, як споживач споживає цю веб-службу.

А тепер уявіть, що на місці вищевказаного веб-сервісу з'явився новий, який розкриває міста як об’єкти. Отже, коли ви дивитесь на нього як на клієнта, замість GetWeatherInfo () ви бачите Нью-Йорк, Даллас, Лос-Анджелес, Лондон тощо. І ці міста не мають жодних прикладних методів, які звисають до них - вони, схоже, інертні гази - вони самі не реагують.

Ви, мабуть, думаєте - ну як це допомагає вам, як клієнту, дістатися до погоди Далласа? До цього ми дістанемося через кілька моментів.

Якщо все, що ви отримуєте від веб-сервісу, - це «набір об’єктів», очевидно, вам потрібен спосіб «діяти на них». Самі об’єкти не мають методів виклику, тому вам потрібен набір дій, які ви можете застосувати до цих об'єктів. Іншими словами, вам потрібно «застосувати дієслово до іменника». Якщо ви бачите предмет, скажімо, яблуко, яке є "іменником", ви можете застосувати до нього "дієслово", як їсти. Але не всі дієслова можуть бути застосовані до всіх іменників. Мовляв, ти можеш керувати автомобілем, але не можеш керувати телевізором.

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

Ось кілька ідей:

• REST обмежує вашу послугу використовувати єдиний інтерфейс. Вам не доведеться витрачати час на мріяння (або сперечаючись) про всі можливі способи роботи вашої служби - ви отримаєте право працювати над визначенням ресурсів у вашій системі. Виявляється, це сама велика робота, але, на щастя, проблеми, як правило, визначаються набагато краще.
• З ресурсами, їх об'єднаннями та представництвами в роботі насправді дуже мало робити в реалізації вашої послуги, оскільки для вас було прийнято багато рішень.
• Ваша система буде дуже схожа на інші системи RESTful; Криві навчання колег, партнерів та клієнтів будуть зменшені.
• У вас буде загальний словник, щоб обговорити проблеми дизайну з іншими розробниками, і навіть з тими менш технічно налаштованими (такими як клієнти).
• Як каже Даррел, оскільки ви використовуєте дизайн, керований гіпертекстом , ваша послуга звужує сферу зв'язку лише до одного - типів носія. Це допомагає вам як розробнику, оскільки зміни у вашій системі містяться у вузькій смузі контактів. Це допомагає вашим клієнтам у тому, що менша кількість ваших змін порушить їх код.
• Практично кожну проблему, яка може виникнути при впровадженні REST, можна вирішити, відкривши новий ресурс або переосмисливши свою ресурсну модель. Цей фокус є, IMO, великим підвищенням продуктивності.

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

Більшість "профі" відповідей про REST, схоже, надходять від людей, які ніколи не розробляли веб-службу SOAP або клієнта, використовуючи середовище, яке забезпечує відповідні інструменти для виконання завдання. Вони скаржаться на проблеми, з якими я просто ніколи не стикався, використовуючи Visual Studio .NET та Rational Web Developer. Я припускаю, що якщо вам доведеться розробляти веб-сервіси або клієнтів на мові сценаріїв чи іншою мовою з малою підтримкою інструментів або взагалі, це справжні скарги.

Я також мушу визнати, що кілька "про" пунктів звучать як речі, які насправді можуть бути правдивими, - але я ніколи не бачив приклад, який ілюструє їхню цінність. Зокрема, я дуже вдячний, якщо хтось опублікує коментар, що містить посилання на хороший приклад веб-сервісу REST. Це має бути той, хто використовує декілька рівнів ресурсів, можливо в ієрархії, і використовує типи медіа належним чином. Можливо, якщо я дивлюсь на хороший приклад, я зрозумію, у такому випадку я повернусь сюди і зізнаюся.

Щоб додати дещо прозаїчне відвертання до вже відповідей, зважаючи на те, що ми використовуємо послуги REST, де я є, це те, що якщо ви знаєте, ви можете передати діловому партнеру URL-адресу і знаєте, що вони отримають, взамін, чудово викладену плитку XML незалежно від того, працюють вони.

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

Окрім технічних переваг, непогано пояснити, продемонструвати, продемонструвати та почути себе впевнено - це добре. SOAP, хоча настільки ж крутий для технологій набагато менш доступний для нетехнологів, а тому «продати» його не так просто.

Я, як правило, помічаю, що речі, які не мають технологій, можуть закручуватися, як правило, прилипають. Тому я сумніваюся, що REST як техніка може бути настільки ж сприйнятливим, як SOAP до примх мод.

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

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

Багато в чому саме Всесвітня павутина, заснована на HTTP, може розглядатися як архітектура на основі REST. Програми RESTful використовують запити HTTP для розміщення даних (створення та / або оновлення), зчитування даних (наприклад, здійснення запитів) та видалення даних. Таким чином, REST використовує HTTP для всіх чотирьох операцій CRUD (Create / Read / Update / Delete).

REST - це легка альтернатива таким механізмам, як RPC (віддалені виклики процедури) та веб-сервіси (SOAP, WSDL та ін.). Пізніше ми побачимо, наскільки простішим є REST.

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