Вікі-код для Json-RPC vs REST & GraphQL
Сховати останніх авторів
author | version | line-number | content |
---|---|---|---|
![]() |
1.1 | 1 | (% class="jumbotron" %) |
2 | ((( | ||
3 | (% class="container" %) | ||
4 | ((( | ||
![]() |
1.3 | 5 | = Мій погляд на сучасні API = |
![]() |
1.1 | 6 | |
![]() |
1.3 | 7 | Спробую тут викласти свою думку і пояснити чому Json-RPC кращій вибір для побудови API |
![]() |
1.1 | 8 | ))) |
9 | ))) | ||
10 | |||
![]() |
1.4 | 11 | {{box cssClass="floatinginfobox" width="400px" title="**Зміст**"}} |
12 | {{toc/}} | ||
13 | {{/box}} | ||
14 | |||
![]() |
1.3 | 15 | Сучасні технології передачі даних визначають темп розвитку багатьох галузей і способів ведення бізнесу. По мірі того, як компанії вимагають більшої швидкості, адаптивності та ефективності від своїх систем, також зростає потреба в передових методах розробки API. Одним з таких методів, який виокремлюється своєю ефективністю та гнучкістю, є JSON-RPC, метод, який часто недооцінюють на фоні більш популярних REST та GraphQL. |
![]() |
1.1 | 16 | |
![]() |
1.3 | 17 | == Аналіз REST та GraphQL == |
![]() |
1.1 | 18 | |
![]() |
1.3 | 19 | **REST**, який домінував у веб-розробці протягом останніх десятиліть, став популярним через свою зручність інтеграції з HTTP, але дуже часто він використовується за інерцією, просто через те, що розробник вже звик до нього і не помічає "костилів" які змушений робити з проєкта в проєкт щоб покрити вимоги бізнес-логіки. Невідворотньо по мірі росту складності додатків і зростання вимог до них, REST починає виявляти свою недостатність, оскільки цей підхід може вимагати численних запитів до сервера для виконання простих операцій та погано масштабується для складних систем. |
![]() |
1.1 | 20 | |
![]() |
1.3 | 21 | **GraphQL** вирішує деякі з цих проблем, дозволяючи клієнтам визначати, які дані їм потрібні, в одному запиті. Проте цей метод також вносить власні виклики: складність реалізації на бекенді, зростання навантаження на сервер через складність запитів і потенційну неефективність використання ресурсів. |
![]() |
1.1 | 22 | |
![]() |
1.3 | 23 | А найголовніша проблема цих двох підходів в тому, що і REST, і GraphQL це ресурсно-орієнтовані стандарти. Їх основна задача це перенесення елементарної роботи з базою даних на рівень клієнта, тобто надання CRUD на рівні HTTP запитів (хоча в поняття "ресурс" може вкладатися і певна абстракція). Зазвичай в реальних системах таких запитів не більше третини від всього бекенду API, а для інших потреб доводиться вигадувати велосипеди. |
24 | |||
25 | Спроба зробити весь API максимально RESTful сильно збільшує обсяги коду і вантажить мережу, бо решта двох третин запитів - у формі команд на бекенд зводиться до дії, що слабко повʼязані з CRUD над ресурсами. Варіантів надіслати такі запити занадто багато і вони ніяк нне регламентовані: GET, POST, PUT, PATCH, HTTP заголовки, куки, body, дані форм, GET query параметри, json, content-type, HTTP коди... | ||
26 | |||
27 | Коли в команді кілька розробників, і в кожного свій погляд на світобудову, досить швидко це перетворюється на вінегрет. Навіть один розробник часто опиняється в глухому куті в нерозумінні як далі жити з усім цим місивом параметрів, дієслів і іменників RESTlike API . | ||
28 | |||
![]() |
1.4 | 29 | == Все геніальне - просте! == |
![]() |
1.1 | 30 | |
![]() |
1.4 | 31 | Пошук рішення висвітлених проблем призвів до створення простої, зрозумілої і на мій погляд (% class="mark" %)абсолютно недооціненої(%%) [[специфікації JSON-RPC>>https://www.jsonrpc.org/specification]]. Ця специфікація повністю відокремлює бізнес-логіку клієнт-серверного запиту від HTTP з його багатим, але не потрібним внутрішнім світом. |
![]() |
1.1 | 32 | |
![]() |
1.4 | 33 | = Переваги Json-RPC = |
![]() |
1.1 | 34 | |
![]() |
1.5 | 35 | === Стандартизація та Гнучкість === |
![]() |
1.1 | 36 | |
![]() |
1.5 | 37 | JSON-RPC є яскравим прикладом еволюції архітектурних підходів у розробці веб-додатків і системних інтерфейсів. Цей протокол дозволяє віддалено викликати процедури на сервері, надсилаючи запити через HTTP POST у формі JSON-об'єктів. Саме ця універсальність і простота забезпечують високий рівень інтеграції та взаємодії між компонентами розподілених систем. |
38 | |||
39 | ==== Стандартизація Запитів і Відповідей ==== | ||
40 | |||
41 | У JSON-RPC всі запити та відповіді стандартизовані, що значно спрощує розробку та підтримку API. Кожен запит містить два основних компоненти: | ||
42 | |||
43 | * **Method**: Назва методу або процедури, яка повинна бути викликана на сервері. Це аналогічно ендпойнту в REST, але забезпечує більшу гнучкість, оскільки не обмежується стандартними HTTP-методами. | ||
44 | * **Params**: Параметри, які передаються разом із запитом. Вони можуть бути представлені у вигляді масиву або об'єкта залежно від конкретного методу. | ||
45 | |||
46 | ==== Відповіді сервера також дуже структуровані і передбачувані, включаючи: ==== | ||
47 | |||
48 | * **Result**: Результат виконання процедури, якщо вона була успішною. | ||
49 | * **Error**: Інформація про помилку, якщо в процесі виконання процедури виникли проблеми. | ||
50 | |||
51 | ==== Відмінності від REST ==== | ||
52 | |||
53 | На відміну від REST, який орієнтований на роботу з ресурсами і базується на CRUD-операціях (Створення, Читання, Оновлення, Видалення), JSON-RPC не обмежується чотирма базовими операціями і дозволяє визначати майже необмежену кількість процедур. Це робить JSON-RPC ідеальною альтернативою для сценаріїв, де потрібне виконання складних та специфічних операцій, які важко моделювати через стандартні HTTP-запити. | ||
54 | |||
55 | ==== Використання JSON для Обміну Даними ==== | ||
56 | |||
57 | Назва "JSON-RPC" походить від формату обміну даними (JSON), який є легким, легко читаним для людей і одночасно машиночитабельним. Це дозволяє системам легко обмінюватися даними через мережі, не залежно від мови програмування, яка використовується для реалізації клієнтських та серверних компонентів. JSON забезпечує високу гнучкість і швидкість обробки даних, що є критично важливим для розробки сучасних веб-додатків та мобільних застосунків. | ||
58 | |||
59 | == Ефективність та спрощення розробки == | ||
60 | |||
![]() |
1.4 | 61 | JSON-RPC мінімізує кількість запитів до сервера, оскільки він дозволяє виконання декількох дій в рамках одного запиту. Це не тільки знижує навантаження на мережу, але й полегшує інтеграцію для розробників, звільняючи їх від потреби розбиратися в складностях багатьох HTTP-методів. |
![]() |
1.1 | 62 | |
![]() |
1.5 | 63 | == Гнучкість та масштабованість == |
![]() |
1.4 | 64 | |
65 | Оскільки JSON-RPC не залежить від транспортного протоколу, він може бути використаний з різними протоколами передачі даних і легко адаптується до змін в технічних вимогах абсолютно не змінюючи код виконавця. | ||
66 | |||
![]() |
1.5 | 67 | === Транспортна Незалежність JSON-RPC === |
![]() |
1.4 | 68 | |
![]() |
1.5 | 69 | Однією з ключових переваг JSON-RPC є його транспортна незалежність. На відміну від багатьох інших протоколів, які є тісно пов'язаними з конкретними транспортними механізмами (наприклад, REST, який переважно використовує HTTP), JSON-RPC може функціонувати на різних транспортних протоколах. Це означає, що він може бути легко інтегрований із різними системами та адаптований до різних мережевих умов без втрати функціональності або ефективності. |
70 | |||
71 | ==== Гнучкість у Виборі Транспортних Протоколів ==== | ||
72 | |||
73 | JSON-RPC може використовуватись через HTTP, WebSockets, TCP, UDP та інші транспортні протоколи, що робить його вкрай гнучким варіантом для розробників. Ця транспортна незалежність дозволяє використовувати JSON-RPC у різних сценаріях використання, включаючи високопродуктивні розподілені системи, реальні веб-додатки, а також у вбудованих системах і IoT-проектах. | ||
74 | |||
75 | ==== Переваги транспортної незалежності: ==== | ||
76 | |||
77 | * **Сумісність з різними середовищами**: JSON-RPC не вимагає специфічних для протоколу реалізацій, що забезпечує його легке впровадження в існуючі системи без необхідності перебудови або значних змін. | ||
78 | * **Масштабованість**: Здатність працювати з різними транспортними протоколами дозволяє JSON-RPC масштабуватися відповідно до потреб проекту, включаючи можливість оптимізації для високої продуктивності або забезпечення більшої надійності. | ||
79 | * **Ефективність**: Використання оптимального транспортного протоколу для конкретних умов дозволяє знижувати затримки, оптимізувати швидкість передачі даних та зменшувати навантаження на мережу. | ||
80 | |||
81 | ==== Практичне Застосування ==== | ||
82 | |||
83 | Впровадження JSON-RPC у комплексні системи, які вимагають швидкої обробки великих обсягів даних або реальної взаємодії з користувачем, може значно покращити їхню ефективність. Наприклад, використання WebSockets для постійного обміну даними між клієнтом та сервером у реаль | ||
84 | |||
85 | == Оптимізація взаємодії між системами == | ||
86 | |||
![]() |
1.4 | 87 | JSON-RPC забезпечує гнучку взаємодію між різними системами, відокремлюючи бізнес-логіку від транспортного прошарку. Це дозволяє розробникам фокусуватися на логіці додатку, а не на деталях імплементації комунікації. |
88 | |||
![]() |
1.5 | 89 | == Вплив на розвиток бізнес-логіки == |
![]() |
1.4 | 90 | |
![]() |
1.5 | 91 | JSON-RPC відкриває нові можливості для створення модульних та гнучких систем. Розробники можуть визначати специфічні бізнес-операції як окремі процедури, що дозволяє динамічно змінювати та розширювати функціональність без переписування існуючого коду. Такий підхід значно підвищує швидкість розробки нових функцій та дозволяє більш гнучко реагувати на динамічні вимоги ринку. |
92 | |||
![]() |
1.1 | 93 | = Paragraph 2 = |
94 | |||
95 | Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. | ||
96 | |||
97 | == Sub-paragraph == | ||
98 | |||
99 | Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. | ||
100 | |||
101 | == Sub-paragraph == | ||
102 | |||
103 | Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. | ||
![]() |
1.4 | 104 | ~)~)~) |