Json-RPC vs REST & GraphQL

Остання зміна 2024/05/20 12:54 автором Ashterix

rpc_vs_rest_vs_grafql

Мій погляд на сучасні API

Спробую тут викласти свою думку і пояснити чому Json-RPC кращій вибір для побудови API

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

Аналіз REST та GraphQL

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

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

А найголовніша проблема цих двох підходів в тому, що і REST, і GraphQL це ресурсно-орієнтовані стандарти. Їх основна задача це перенесення елементарної роботи з базою даних на рівень клієнта, тобто надання CRUD на рівні HTTP запитів (хоча в поняття "ресурс" може вкладатися і певна абстракція). Зазвичай в реальних системах таких запитів не більше третини від всього бекенду API, а для інших потреб доводиться вигадувати велосипеди.

Спроба зробити весь API максимально RESTful сильно збільшує обсяги коду і вантажить мережу, бо решта двох третин запитів - у формі команд на бекенд зводиться до дії, що слабко повʼязані з CRUD над ресурсами. Варіантів надіслати такі запити занадто багато і вони ніяк нне регламентовані: GET, POST, PUT, PATCH, HTTP заголовки, куки, body, дані форм, GET query параметри, json, content-type, HTTP коди...

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

Все геніальне - просте!

Пошук рішення висвітлених проблем призвів до створення простої, зрозумілої і на мій погляд абсолютно недооціненої специфікації Json-RPC. Ця специфікація повністю відокремлює бізнес-логіку клієнт-серверного запиту від HTTP з його багатим, але не потрібним внутрішнім світом.

Переваги Json-RPC

Json-RPC є яскравим прикладом еволюції архітектурних підходів у розробці веб-додатків і системних інтерфейсів. Цей протокол дозволяє віддалено викликати процедури на сервері, надсилаючі команди у вигляді Json-об'єктів. В якості транспорту можна обрати будь-яку доступну технологію, наприклад HTTP POST запити. Саме ця універсальність і простота забезпечують високий рівень інтеграції та взаємодії між компонентами розподілених систем.

Стандартизація Запитів і Відповідей

У Json-RPC всі запити та відповіді стандартизовані, що значно спрощує розробку та підтримку API. Кожен запит містить два основних компоненти:

  • Method: Назва методу або процедури, яка повинна бути викликана на сервері. Це аналогічно ендпойнту в REST, але забезпечує більшу гнучкість, оскільки не обмежується стандартними HTTP-методами.
  • Params: Параметри, які передаються разом із запитом. Вони можуть бути представлені у вигляді масиву або об'єкта залежно від конкретного методу.

Відповіді сервера також структуровані і передбачувані, включаючи:

  • Result: Результат виконання процедури, якщо вона була успішною.
  • Error: Інформація про помилку, якщо в процесі виконання процедури виникли проблеми.

Відмінності від REST

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

Використання Json для обміну даними

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

Batch запроси

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

Транспортна Незалежність Json-RPC

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

Гнучкість у Виборі Транспортних Протоколів

Json-RPC може використовуватись через HTTP, WebSockets, TCP, UDP та інші транспортні протоколи, що робить його вкрай гнучким варіантом для розробників. Ця транспортна незалежність дозволяє використовувати Json-RPC у різних сценаріях використання, включаючи високопродуктивні розподілені системи, реальні веб-додатки, а також у вбудованих системах і IoT-проектах.

Переваги транспортної незалежності:

  • Сумісність з різними середовищами: Json-RPC не вимагає специфічних для протоколу реалізацій, що забезпечує його легке впровадження в існуючі системи без необхідності перебудови або значних змін.
  • Масштабованість: Здатність працювати з різними транспортними протоколами дозволяє Json-RPC масштабуватися відповідно до потреб проекту, включаючи можливість оптимізації для високої продуктивності або забезпечення більшої надійності.
  • Ефективність: Використання оптимального транспортного протоколу для конкретних умов дозволяє знижувати затримки, оптимізувати швидкість передачі даних та зменшувати навантаження на мережу.

Практичне Застосування

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

Вплив на розвиток бізнес-логіки

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

Висновок

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

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