REST проти JSON-RPC? [зачинено]

Я намагаюся вибрати між REST та JSON-RPC для розробки API для веб-додатків. Як вони порівнюються?

Оновлення 2015: Я знайшов REST простішим у розробці та використанні для API, який подається в Web / HTTP, оскільки існуючий та зрілий протокол HTTP, який розуміється і клієнтом, і сервером, може використовувати API. Наприклад, коди відповідей, заголовки, запити, органи публікації, кешування та багато інших функцій можуть використовуватися API без додаткових зусиль чи налаштувань.

Принциповою проблемою з RPC є з'єднання. Клієнти RPC тісно поєднуються з реалізацією послуги декількома способами, і змінити реалізацію послуги, не порушуючи клієнтів, стає дуже важко:

• Клієнти повинні знати назви процедур;
• Порядок параметрів процедури, типи та кількість питань. Не так просто змінити підписи процедури (кількість аргументів, порядок аргументів, типи аргументів тощо) на стороні сервера, не порушуючи реалізацію клієнта;
• Стиль RPC не виставляє нічого, крім кінцевих точок процедури + аргументів процедури. Клієнт неможливо визначити, що можна зробити далі.

З іншого боку, у стилі REST дуже просто керувати клієнтами, включаючи керуючу інформацію у представлення (HTTP заголовки + представлення). Наприклад:

• Можна вбудовувати посилання з анотованими типами відношень посилань, які передають значення цих URI;
• Реалізація клієнта не повинна залежати від конкретних назв та аргументів процедури. Натомість клієнти залежать від форматів повідомлень. Це створює можливість використовувати вже реалізовані бібліотеки для конкретних медіа форматів (наприклад, Atom, HTML, Collection + JSON, HAL тощо).
• Можна легко змінити URI, не порушуючи клієнтів, наскільки вони залежать лише від зареєстрованих (або доменних) зв’язків зв’язків;
• Можна вбудовувати подібні структури в представлення, даючи клієнтам можливість викрити ці описи як можливості інтерфейсу, якщо кінцевий користувач є людиною;
• Підтримка кешування - додаткова перевага;
• Стандартизовані коди статусу;

Є ще багато відмінностей та переваг на стороні REST.

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

Якщо ви приймаєте рішення про RPC, єдиною різницею є те, що ви чітко вказуєте дієслово як частину URI, що чітко, послідовно, менше баггі та насправді не викликає проблем. Особливо, якщо ви створюєте додаток, який виходить за рамки простого CRUD, єдиний шлях - RPC. У мене є ще одна проблема з RESTful пуристами: HTTP POST, GET, PUT, DELETE мають певні значення в HTTP, які REST перекосили в інші речі, просто тому, що вони підходять більшу частину часу - але не весь час.

У програмуванні я давно виявив, що намагання використовувати одну річ, щоб означати дві речі, коли-небудь обернеться і вкусить вас. Мені подобається мати можливість використовувати POST майже для кожної дії, оскільки це забезпечує свободу надсилання та отримання даних, як це потрібно зробити. Ви не можете вмістити весь світ у CRUD.

По-перше, HTTP-REST - це архітектура перенесення стану репрезентації. Це передбачає багато цікавого:

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

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

І останнє, але не менш важливе, використання HTTP як протоколу RPC - це величезна помилка, на думку дизайнера HTTP 1.1 (і винахідника REST): http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Чудові відповіді - просто хотілося уточнити в деяких коментарях. JSON-RPC швидко та легко споживається, але, як згадуються ресурси та параметри, тісно пов'язані між собою і він, як правило, покладається на дієслова (api / deleteUser, api / addUser), використовуючи GET / POST, де REST надає вільно пов'язані ресурси (api / користувачів), що в HTTP REST API покладається на кілька методів HTTP (GET, POST, PUT, PATCH, DELETE). REST трохи складніше реалізовувати недосвідченим розробникам, але зараз стиль став досить поширеним, і він забезпечує набагато більшу гнучкість у довгостроковій перспективі (надаючи API більш тривалий термін експлуатації).

Поряд з тим, що не має щільно зв'язаних ресурсів, REST також дозволяє вам уникнути прихильності до одного типу контенту - це означає, якщо клієнту потрібно отримувати дані в XML, або JSON, або навіть YAML - якщо вбудований у вашу систему, ви могли б повернути будь-кого з тих, хто використовує заголовки типу вмісту / приймати.

Це дозволяє вам підтримувати API досить гнучким для підтримки нових типів вмісту АБО вимог клієнта.

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

Однак, маючи все це сказане - API MOST не є RESTful (згідно Fielding), оскільки вони не містять гіпермедіа (вбудовані гіпертекстові посилання у відповідь, які допомагають орієнтуватися в API). Більшість API, які ви дізнаєтесь, є як REST, оскільки вони слідують більшості концепцій REST, але ігнорують це обмеження. Однак все більше і більше API реалізують це, і це стає все більш практичною практикою.

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

Взагалі, я б сказав, що REST - це шлях, якщо ви хочете побудувати розширюваний, гнучкий API, який буде довготривалим. З цієї причини я б сказав, що це маршрут, який потрібно пройти 99% часу.

Удачі, Майку

ІМО, ключовим моментом є орієнтація на дії та ресурси. REST орієнтований на ресурси та добре підходить для операцій CRUD, а з огляду на його відому семантику забезпечує деяку передбачуваність для першого користувача, але при застосуванні методів чи процедур змушує вас надати штучний переклад у світ, орієнтований на ресурси. З іншого боку, RPC ідеально підходить для орієнтованих на дії API, де ви відкриваєте послуги, а не набори ресурсів, здатні на CRUD.

Без сумніву, REST популярніший, але це, безумовно, додає певних балів, якщо ви хочете винести API сторонній стороні.

Якщо ні (наприклад, у випадку створення фронтального AJAX в SPA), мій вибір - RPC. Зокрема, JSON-RPC поєднується зі схемою JSON як мовою опису та транспортується через HTTP або Websockets залежно від випадку використання.

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

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

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

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

http://rpc.brutusin.org

Тут ви можете побачити демонстрацію в реальному часі, показуючи вбудований браузер репозиторію для функціонального тестування (завдяки JSON Schema) та ряд прикладних служб:

http://demo.rpc.brutusin.org

Сподіваюсь, це допоможе товаришеві!

Начо

Якщо ваша послуга прекрасно працює лише з моделями та схемою GET / POST / PUT / DELETE, використовуйте чистий REST.

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

Але для сучасних, більш складних (!) Додатків у режимі реального часу (Інтернету), де ви хочете використовувати Websockets (які часто означають репутацію), чому б не використовувати обидва? JSON-RPC через Websockets дуже легкий, тому у вас є такі переваги:

• Миттєві оновлення кожного клієнта (визначте власний дзвінок RPC від сервера до клієнта для оновлення моделей)
• Легко додати складність (спробуйте зробити клон Etherpad лише REST)
• Якщо ви зробите це правильно (додайте RPC лише як додатковий в режимі реального часу), більшість з них все ще може використовуватися лише REST (за винятком випадків, коли головною особливістю є чат чи щось таке)

Оскільки ви лише розробляєте серверний API, почніть з визначення REST-моделей і пізніше додайте підтримку JSON-RPC за необхідності, зводячи до мінімуму кількість викликів RPC.

(і вибачте за непомірне використання дужок)

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

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

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

Через це RPC сьогодні відчуває мене набагато простіше і природніше. Те, що мені дуже не вистачає, - це послідовна рамка, яка дозволяє легко писати служби RPC, які є самоописом та сумісними. Тому я створив власний проект для експерименту з новими способами полегшити RPC для себе, і, можливо, хтось ще вважає це корисним: https://github.com/aheck/reflectrpc

Відповідно до моделі зрілості Річардсона , питання не в REST проти RPC , а в тому, скільки REST ?

На цей погляд, відповідність стандарту REST можна класифікувати на 4 рівні.

• рівень 0: продумайте дії та параметри. Як пояснюється у статті, це по суті еквівалентно JSON-RPC (стаття пояснює це для XML-RPC, але для обох є однакові аргументи).
• рівень 1: мислити з точки зору ресурсів. Все, що стосується ресурсу, належать до однієї URL-адреси
• рівень 2: використовувати дієслова HTTP
• рівень 3: HATEOAS

За словами творця стандарту REST, лише послуги 3 рівня можна назвати RESTful. Однак це показник відповідності , а не якості. Якщо ви просто хочете викликати віддалену функцію, яка виконує обчислення, напевно, немає сенсу мати відповідні гіперпосередкові зв’язки у відповіді, а також диференціацію поведінки на основі використовуваного дієслова HTTP. Отже, такий виклик за своєю суттю має тенденцію бути більш подібним до RPC. Однак нижчий рівень відповідності не обов'язково означає державність або вищу взаємодію. Можливо, замість того, щоб думати REST проти RPC , ви повинні використовувати якомога більше REST, але не більше. Не перекручуйте додаток лише для того, щоб він відповідав стандартам RESTful відповідності.

Чому JSON RPC:

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

Інший фактор - навіть якщо ми маємо різні контролери для кожного методу / функціональності, клієнт повинен пам’ятати, чим раніше використовувати POST або GET. Це ще більше ускладнює справи. Крім того, щоб надсилати дані, потрібно встановити тип вмісту запиту, якщо використовується POST.

У випадку JSON RPC все значно спрощується, оскільки більшість серверів JSONRPC працюють за методами POST HTTP, а тип вмісту завжди є application / json. Це знімає навантаження на запам'ятовування, щоб використовувати належний метод HTTP та налаштування вмісту на стороні клієнта.

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

Чому ПОЧАТИ:

У вас є окремі URL-адреси для різних функціональних можливостей, які сервер хоче піддати клієнтові. Як результат, ви можете вставити ці URL-адреси.

Більшість із цих питань є дискусійними та повністю залежать від потреби людини.

Я думаю, як завжди, це залежить ...

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

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

Я колись починав з REST для однієї сторінки веб-програми, але дрібнозернисті команди між веб-додатком та сервером швидко звели мене з розуму. Чи слід кодувати його як параметр шляху? В організмі? Параметр запиту? Заголовок? Після дизайну URL / Verb / Response мені довелося кодувати цей безлад у Javascript, декодері в Java, а потім викликати власне метод. Незважаючи на те, що для цього існує безліч інструментів, дуже важко не отримувати HTTP-семантики у вашому доменному коді, що є дуже поганою практикою. (Згуртованість)

Спробуйте створити файл Swagger / OpenAPI для середньоскладного сайту та порівняйте його з єдиним інтерфейсом Java, який описує віддалені процедури у цьому файлі. Зростання складності є приголомшливим.

Тому я перейшов з REST на JSON-RPC для однієї сторінки webapp. a я розробив крихітну бібліотеку, яка закодувала інтерфейс Java на сервері та відправила його до браузера. У браузері це створило проксі для коду програми, який повертав обіцянку для кожної функції.

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

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

Було б краще вибрати JSON-RPC між REST та JSON-RPC, щоб розробити API для веб-додатків, який легше зрозуміти. JSON-RPC є кращим, оскільки його відображення до викликів методів та комунікацій легко зрозуміти.

Вибір найбільш підходящого підходу залежить від обмежень або основної мети. Наприклад, що стосується того, що продуктивність є головною ознакою, доцільно звернутися до JSON-RPC (наприклад, High Performance Computing). Однак, якщо головна мета - агностик, щоб запропонувати загальний інтерфейс, який слід зробити іншим, доцільно перейти на REST. Якщо вам потрібно досягти обох цілей, бажано включити обидва протоколи.

Те, що насправді розділяє REST від JSON-RPC, - це те, що він проходить ряд ретельно продуманих обмежень, що підтверджують архітектурну гнучкість. Обмеження полягають у тому, що клієнт та сервер здатні рости незалежно один від одного (зміни можна проводити, не псуючи додаток клієнта), дзвінки без громадянства (стан розглядають як гіпермедіа), єдину форму Інтерфейс пропонується для взаємодії, API вдосконалений у багатошаровій системі (Hall, 2010). JSON-RPC є швидким і простим у споживанні, однак, як згадані ресурси, так і параметри тісно пов'язані, і це, ймовірно, залежить від дієслів (api / addUser, api / deleteUser) за допомогою GET / POST, тоді як REST надає вільно пов'язані ресурси (api / користувачів) у HTTP. API REST залежить від декількох методів HTTP, таких як GET, PUT, POST, DELETE, PATCH.

JSON (позначається як JavaScript Object Notation) як легкий формат обміну даними, для людей легко читати та писати. Машини розбирають і генерують без проблем. JSON - це текстовий формат, повністю незалежний від мови, але практикує конвенції, знайомі програмістам сімейства мов, що складаються з C #, C, C ++, Java, Perl, JavaScript, Python та багатьох інших. Такі властивості роблять JSON ідеальним мовою обміну даними та кращим вибором.

Неправильне питання: нав'язує маніхея, якого не існує!

Ви можете використовувати JSON-RPC з "менш дієсловом" (без методу ) і зберегти мінімальну стандартизацію, необхідну для ідентифікатора sendo, параметрів, кодів помилок та попередження повідомлень. Стандарт JSON-RPC не говорить "ти не можеш бути REST", а лише сказати, як упакувати основну інформацію.

"REST JSON-RPC" існує ! REST з "найкращими методами", для мінімальної упаковки інформації, з простими та надійними контрактами.

Приклад

(з цієї відповіді та дидактичного контексту)

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

• REST Депозит із POST /Bank/Account/John/Transactionзапитом JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  Відповідь JSON може бути щось подібне{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• ВІДКРИТТЯ Зняти з POST /Bank/Account/John/Transaction... подібним.

• ... GET /Bank/Account/John/Transaction/12345@13... Це може повернути запис JSON про цю точну транзакцію (наприклад, ваші користувачі, як правило, хочуть записувати дебети та кредити на своєму рахунку). Щось таке {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Конвенція про (REST) ​​GET-запит може включати в себе кодування ідентифікатора за допомогою "@id", тому не потрібно надсилати жоден JSON, але все ще використовуючи JSON-RPC у пакеті відповідей.

Якщо ви вимагаєте ресурсів, то RESTful API краще за дизайном. Якщо ви вимагаєте складних даних з великою кількістю параметрів і складних методів, відмінних від простого CRUD, то RPC - це правильний шлях.

Я використовую vdata для протоколу RPC: http://vdata.dekuan.org/

1, PHP та JavaScript - це добре. 2, виклик спільного використання ресурсів (CORS) все ще добре.