Сучасні технології передачі даних визначають темп розвитку багатьох галузей і способів ведення бізнесу. По мірі того, як компанії вимагають більшої швидкості, адаптивності та ефективності від своїх систем, також зростає потреба в передових методах розробки 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 мінімізує кількість запитів до сервера, оскільки він дозволяє виконання декількох дій в рамках одного запиту. Це не тільки знижує навантаження на мережу, але й полегшує інтеграцію для розробників, звільняючи їх від потреби розбиратися в складностях багатьох HTTP-методів.

Гнучкість та масштабованість

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

Оптимізація взаємодії між системами

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

Paragraph 2

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.

Sub-paragraph

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.

Sub-paragraph

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.
)))