REST vs RESTful та “звичайний” веб-сервіс - те саме чи ні?


21

Я прочитав пару визначень та обговорень програм REST та / або RESTful, але все ще не розумію справжнього значення цього.

Я зазвичай працюю з програмами, які або отримують дані через GET, або надсилають дані через POST в якусь веб-службу (зазвичай це сценарій PHP), яка потім або отримує дані з бази даних, або записує в базу даних.

Тепер це ПОБУТНІЙ додаток? Якщо ні, то що б RESTful додаток? Чим відрізняється концепція RESTful від концепції, з якою я працював до цього часу? Поясніть, будь ласка, на прикладі.

Також хтось говорить про REST, а хтось про RESTful додатки. Я виявив, що термін REST відноситься до теоретичної концепції, тоді як RESTful використовується, коли ми говоримо про конкретну програму. Це правильно чи є реальні відмінності між програмами REST та RESTful?


1
Якщо ви можете створити всі сервлети для вилучення інформації з параметрів GET або POST ТОЛЬКО (абсолютно нічого не зберігається локально до виклику), то ви належним чином застосуєте REST. Іншими словами, сервер відіграє роль моделі в MVC тим, що він не контролює, а просто використовує те, що дано для виконання певного завдання. Сподіваюся, що це пояснює це трохи краще.
Ніл

@Neil Я з іншого боку - мобільний додаток. Це клієнт, який використовує веб-сервіс та спілкується з ним через POST та GET. Всі веб-сервіси були побудовані кимось іншим, і все, що я робив, використовував їх. Але термінологія мене збентежила. Отже, якщо я використовую канал HTTP та об’єкти HttpGet / HttpPost, то я маю справу з програмою RESTful, правда?
deviDave

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

@Neil О, я розумію. RESTful робиться на сервері. І якщо я надсилаю поштовий об’єкт із запитом (не кожним параметром окремо), це, ймовірно, підхід REST. Що стосується клієнта (мобільний додаток), то це не байдуже, чи це REST чи ні, так як кодування однакове. Чи правильно я це зробив?
deviDave

2
RESTful - це і сервер, і клієнт, але якщо ви можете бачити лише клієнта, ви можете знати лише, чи дотримується клієнт цих обмежень. Це все, що я мав на увазі. Що я маю на увазі під REST, це якщо вам потрібно увійти в систему, ви публікуєте ім’я користувача та пароль. Сервер перевіряє вхід та зберігає хеш-ключ користувача в базі даних та повертає його. Тепер, коли вам потрібно зробити операцію, яка вимагає входу, ви завжди передаєте хеш-ключ користувача. Сервер "забуває", що він увійшов до вас, але використовує хеш для перевірки стану входу. Якби це не було RESTful, сервер пам’ятає, що ви зареєстровані. Розумієте різницю?
Ніл

Відповіді:


13

Основними атрибутами програм RESTful є: Все спілкування здійснюється через http GET, POST, PUT, DELETE І всі елементи адресовані за допомогою стандартної URL-адреси форми, http://your.site.com/salesapp/salesperson/0000001/detailsтобто лише чистої URL-адреси без параметрів і т.д. , POST, PUT, DELETE визначає, що ви хочете зробити для цього.

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

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


О, поки що я не використовував PUT або DELETE (мобільні додатки зазвичай роблять лише GET і POST), але це дійсно схоже на те, що я робив і зараз роблю. Просто клієнти не використовували терміни REST *, а скоріше "веб-сервіс" та "php скрипт"
deviDave

2
Джеймсе, не могли б ви пояснити, чому слід уникати параметрів запиту? Наприклад, як я можу виразити, що хочу, щоб ресурси фільтрувались певним чином, не вводячи помилкову ієрархію?
Гері Роу

3
@GaryRowe: URL-адреса (без параметрів) визначає ресурс, яким ви хочете маніпулювати. Ви все ще можете мати параметри, але вони не використовуються для ідентифікації ресурсу. Приклад GET у каталозі (URL-адреса, що закінчується на /) повинен повернути список ресурсів у каталозі. Параметр у URL-адресі може бути використаний для визначення фільтра чи порядку сортування або щось подібне.
Мартін Йорк

1
Спасибі, Локі. Джеймс може захотіти відредагувати свою відповідь, щоб відобразити це, оскільки, здається, він не дозволяє використовувати параметри запиту ні за яких обставин, які можуть ввести в оману. Власне, є цікаве спостереження, що перелік ресурсів у каталозі сам по собі є ресурсом, що виражає це поняття.
Гері Роу

REST не вимагає, щоб додаток був заснований на URL-адресах, і не вимагає від вас таких дієслів, як GET, POST, DELETE тощо. Однак для WebApp URL є єдиним варіантом і вищезгаданими дієсловами.
Наваз

6

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

Правильно, тепер, коли я безсоромно вирвався з Вікіпедії, що це насправді означає? Це ефективно означає використання вбудованих команд HTTP, таких як GET, POST, PUT, DELETE та кілька інших рідкісних для спілкування між клієнтом та сервером.

Те, що ви робите, звучить як його додаток RESTFul. Однак, існує велика різниця між добре розробленими і набором "небажаних" веб-сервісів RESTFul. Наприклад, код PHP на іншому кінці GET може виконати зміну стану, що було б визнано неправильним, оскільки GET сприймається як операція лише для читання. Існують тонкі відмінності між тим, як використовуються також POST (новий) та PUT (замінити).

Стаття у Вікіпедії з цього приводу насправді гарна, тому я зупинюсь тут.


Поки я використовував GET (HttpGet) для отримання контенту та POST (HttpPost) для введення / зміни вмісту бази даних. Я надіслав це як параметр HttpPost та PHP скрипту на веб-сервері, перетворив ці параметри в код SQL. Це ПОСЛУГИЙ додаток? Мене цікавить концепція, а не те, наскільки добре зроблено сценарій PHP. Я не встиг.
deviDave

2
Я б досліджував використання PUT у випадку, коли ви замінюєте вміст, його більш ідіоматичний REST, ніж завжди використовуючи POST.
Мартійн Вербург

Так, у такому випадку я використовував би PUT.
deviDave

+1, зазначаючи, що GET має бути реалізовано правильно (тобто є безвідмовним). Така принципова помилка в перші дні.
Гері Роу

@deviDave Ви також можете заглянути PATCH, який призначений для оновлення частини ресурсу. Як справедливо зазначає Мартін, PUT призначений для заміни всього ресурсу.
Гері Роу

4

Перш ніж піти далі, це пов'язане питання може вам допомогти

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

Багато веб - додатки стверджують, що RESTful, але на самому справі лише частково узгоджені з до REST Обмежень (як Мартейн Вербург також посилається у своїй відповіді). Я просто перерахую їх тут, але настійно закликаю вас прочитати статтю:

  • Клієнт – сервер
  • Кешований
  • Багатошарова система
  • Код на вимогу (необов'язково)

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

Від вашого клієнта очікується, що:

  • використовувати дієслова HTTP (наприклад, GET, POST, PUT, DELETE, OPTIONS, PATCH) для виконання відповідних операцій
  • запропонувати Приймати заголовки та розуміти заголовки типу вмісту (наприклад, ви отримуєте деякі XML, яких ви ніколи не бачили, але ви можете використовувати згаданий XSD, щоб створити модель домену на стороні клієнта, яку представляти вашому користувачеві)
  • перейдіть до запропонованих посилань у введеному Вами типі вмісту (наприклад, спонукайте свого користувача чи заявку до висновку, що <link rel="pay" href="http://example.org/orders(1)/payment">у HTML виражається перехід стану для створення ресурсу платежу через POST з тілом, що містить деяку XML, яка представляє реквізити платежу, наприклад номер кредитної картки , кількість тощо)
  • правильно реагувати на широкий спектр кодів статусу HTTP

Якщо це зроблено вище, то його можна вважати клієнтом REST, ви можете назвати це "RESTful додаток", але це швидше означає, що ви використовуєте REST на стороні клієнта, що неправильно, тому краще уникати термін.


3

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

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


Підсумок 1-го абзацу. Так лаконічно. Спасибі!
deviDave

Ще одне, що ти, щоб побачити, чи правильно я це зрозумів. Якщо я (мій додаток) є клієнтом служби REST, я як клієнт не трапляюсь, якщо служба є RESTful чи ні, оскільки кодування завжди однакове (httpget, httppost тощо)? Цей принцип має значення лише для власника серверного сценарію / програми?
deviDave

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

Додамо, SMTP - це інтерфейс RESTful, хоча він використовує різні дієслова від GET, PUT тощо та інший базовий протокол, концепція однакова - ви надсилаєте серверні команди, що базуються на ідентичну силу, на сервер.
gbjbaanb

Не всі REST-запити є ідентичними. Наприклад, видача POST кілька разів призведе до появи нових ресурсів.
Гері Роу
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.