У мене є веб-служба, яка приймає параметри JSON і має конкретні URL-адреси для методів, наприклад:
http://IP:PORT/API/getAllData?p={JSON}
Це точно НЕ ВІДПОЧИНОК, оскільки це не без громадянства. Він враховує файли cookie та має власну сесію.
Це RPC? У чому різниця між RPC та REST?
Відповіді:
Ви не можете чітко розділити REST або RPC, просто подивившись те, що ви опублікували.
Одне обмеження REST полягає в тому, що він повинен бути без громадянства. Якщо у вас сесія, то у вас є штат, тому ви не можете зателефонувати до своєї служби RESTful.
Той факт, що у вас є дія у вашій URL-адресі (тобто getAllData), є показником до RPC. У REST ви обмінюєтесь поданнями, і виконувана вами операція продиктована дієсловами HTTP. Крім того, у REST узгодження вмісту не виконується з ?p={JSON}параметром.
Не знаю, чи є ваша послуга RPC, але це не RESTful. Ви можете дізнатись про різницю в Інтернеті, ось стаття для початку: Розвінчання міфів про RPC та REST . Ви краще знаєте, що знаходиться у вашій службі, тому порівняйте її функції з тим, що таке RPC, і зробіть власні висновки.
Розглянемо наступний приклад API HTTP, що моделює замовлення, розміщені в ресторані.
Розміщення замовлення:
Отримання замовлення:
Оновлення замовлення:
Приклад взято з sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc
Як сказали інші, ключова відмінність полягає в тому, що REST є іменникоцентричним, а RPC - дієслівним. Я просто хотів включити цю чітку таблицю прикладів, що демонструють:
--------------------------- + ---------------------- --------------- + -------------------------- Експлуатація | RPC (операція) | Відпочинок (ресурс) --------------------------- + ---------------------- --------------- + -------------------------- Реєстрація | POST / реєстрація | POST / осіб --------------------------- + ---------------------- --------------- + -------------------------- Подати у відставку | POST / звільнення | ВИДАЛИТИ / persons / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Читаюча людина | GET / readPerson? Personid = 1234 | GET / осіб / 1234 --------------------------- + ---------------------- --------------- + -------------------------- Прочитати список предметів людини | GET / readUsersItemsList? Userid = 1234 | GET / persons / 1234 / items --------------------------- + ---------------------- --------------- + -------------------------- Додати предмет у список людей | POST / addItemToUsersItemsList | POST / person / 1234 / items --------------------------- + ---------------------- --------------- + -------------------------- Оновити елемент | POST / modifyItem | ПУТ / предмети / 456 --------------------------- + ---------------------- --------------- + -------------------------- Видалити елемент | POST / removeItem? ItemId = 456 | ВИДАЛИТИ / items / 456 --------------------------- + ---------------------- --------------- + --------------------------
Примітки
GET /persons/1234), тоді як RPC, як правило, використовує параметри запиту для входів функцій GET /readPerson?personid=1234).GET /persons?height=tall).POST /signupабо POST /personsви включаєте дані, що описують нову особу).Це RPC за допомогою http . Правильна реалізація REST повинна відрізнятися від RPC. Мати логіку для обробки даних, як метод / функція, - це RPC. getAllData () - це розумний метод. REST не може мати інтелект, це повинні бути дані, які можуть бути перевірені зовнішнім інтелектом .
Більшість реалізацій, які я бачив сьогодні, - це RPC, але багато хто помилково називають це REST. REST з HTTP - це рятівник, а SOAP із XML - лиходій. Тож ваша плутанина виправдана, і ви маєте рацію, це НЕ ВІДПУСК.
Протокол Http не робить реалізацію REST. Як REST (GET, POST, PUT, PATCH, DELETE), так і RPC (GET + POST) можуть бути розроблені за допомогою HTTP (наприклад: через проект веб-API у Visual Studio).
Прекрасно, але що тоді таке «РЕСТ»? Модель зрілості Річардсона наведена нижче (узагальнено). Тільки рівень 3 є RESTful.
наприклад: рівень 3 (HATEOAS):
Посилання стверджує, що цей об’єкт можна оновити таким чином і додати таким чином.
Посилання стверджує, що цей об’єкт можна читати лише, і саме так ми це робимо.
Зрозуміло, що відправки даних недостатньо, щоб стати REST, але про те, як запитувати дані, також слід згадати. Але знову ж таки, чому ці 4 кроки? Чому це не може бути просто кроком 4 і назвати його REST? Річардсон просто дав нам поетапний підхід, щоб туди дійти, ось і все.
Ви створили веб-сайти, якими можуть користуватися люди. Але чи можете ви також створювати веб-сайти, придатні для використання на машинах? Саме в цьому майбутнє, і RESTful Web Services покаже вам, як це зробити.
PS: REST надзвичайно популярний, як і автоматизоване тестування, але коли справа стосується реальних прикладів .. ну ..
REST найкраще описати для роботи з ресурсами, де RPC більше стосується дій.
REST розшифровується як представницький державний трансфер. Це простий спосіб організувати взаємодію між незалежними системами. Додатки RESTful зазвичай використовують HTTP-запити для розміщення даних (створення та / або оновлення), читання даних (наприклад, запитів) та видалення даних. Таким чином, REST може використовувати HTTP для всіх чотирьох операцій CRUD (Create / Read / Update / Delete).
RPC в основному використовується для зв'язку між різними модулями для обслуговування запитів користувачів. наприклад, у openstack, як те, як nova, погляд і нейтрон працюють разом при завантаженні віртуальної машини.
Я міг би стверджувати:
Чи зберігає / володіє даними моя організація? Потім RPC: ось копія деяких моїх даних, маніпулюйте копією даних, яку я вам надсилаю, і поверніть мені копію вашого результату.
Чи має викликана сутність / володіє даними? Потім REST: або (1) покажіть мені копію деяких ваших даних, або (2) маніпулюйте деякими своїми даними.
Зрештою, мова йде про те, яка «сторона» дії володіє / зберігає дані. І так, ви можете використовувати REST verbiage для спілкування з системою, що базується на RPC, але ви все одно будете робити RPC-діяльність, роблячи це.
Приклад 1: У мене є об'єкт, який здійснює зв'язок із реляційним сховищем баз даних (або будь-яким іншим типом сховища даних) через DAO. Має сенс використовувати стиль REST для взаємодії між моїм об’єктом та об’єктом доступу до даних, який може існувати як API. Моя сутність не володіє / не зберігає дані, а реляційна база даних (або нереляційне сховище даних).
Приклад 2: Мені потрібно зробити багато складної математики. Я не хочу завантажувати купу математичних методів у свій об’єкт, я просто хочу передати деякі значення іншому, що може робити всі види математики, і отримати результат. Тоді стиль RPC має сенс, оскільки математичний об'єкт / сутність відкриє моєму об'єкту цілу купу операцій. Зверніть увагу, що всі ці методи можуть бути представлені як окремі API, і я можу викликати будь-який із них за допомогою GET. Я навіть можу стверджувати, що це RESTful, тому що я телефоную через HTTP GET, але насправді під ковдрами це RPC. Моя сутність володіє / зберігає дані, віддалена сутність просто виконує маніпуляції з копіями даних, які я надіслав їй.
Тут є купа хороших відповідей. Я все одно звернуся до цього блогу Google, оскільки він дійсно добре обговорює відмінності між RPC та REST та фіксує те, що я не читав ні в одній з відповідей тут.
Я б цитував абзац із того самого посилання, яке мені виділялося:
Сам REST - це опис принципів дизайну, що лежать в основі HTTP та всесвітньої мережі. Але оскільки HTTP - єдиний комерційно важливий REST API, ми в основному можемо уникати обговорення REST і просто зосередитись на HTTP. Ця заміна корисна, оскільки існує багато плутанини та мінливості у тому, що, на думку людей, означає REST в контексті API, але є набагато більша чіткість і згода щодо того, що таке сам HTTP. Модель HTTP є ідеальним зворотом до моделі RPC - у моделі RPC адресовані одиниці є процедурами, а сутності проблемного домену приховані за процедурами. У моделі HTTP адресними одиницями є самі сутності, а поведінка системи прихована за сутностями як побічні ефекти їх створення, оновлення або видалення.
Ось як я розумію і використовую їх у різних випадках використання:
Приклад: Управління рестораном
варіант використання для REST : управління замовленнями
- create order (POST), update order (PATCH), cancel order (DELETE), retrieve order (GET)
- endpoint: /order?orderId=123
Для управління ресурсами REST є чистим. Одна кінцева точка із заздалегідь визначеними діями. Це можна побачити як виставити екземпляри БД (Sql або NoSql) або класу всьому світу.
Приклад реалізації:
class order:
on_get(self, req, resp): doThis.
on_patch(self, req, resp): doThat.
Приклад фреймворку: Falcon для python.
варіант використання для RPC : управління операцією
- prepare ingredients: /operation/clean/kitchen
- cook the order: /operation/cook/123
- serve the order /operation/serve/123
Для аналітичних, оперативних, невідповідних, нерепрезентативних, заснованих на дії, RPC працює краще, і цілком природно думати функціонально.
Приклад реалізації:
@route('/operation/cook/<orderId>')
def cook(orderId): doThis.
@route('/operation/serve/<orderId>')
def serve(orderId): doThat.
Приклад фреймворку: колба для python