init
uk/articles/api/rpc_vs_rest_vs_graphql.md
новий файл +91
−0
1
+
# Json-RPC vs REST vs GraphQL
2
+
3
+
Спробую коротко і практично пояснити, чому в багатьох реальних проєктах Json-RPC є сильнішою базою для API, ніж REST або GraphQL.
4
+
5
+
6
+
## Вступ
7
+
8
+
REST і GraphQL давно стали популярними стандартами. Але зі зростанням складності систем часто виявляється, що головна частина API не зводиться до простого CRUD над ресурсами.
9
+
10
+
Коли бізнес-логіка стає складною, командам потрібен підхід, який:
11
+
12
+
- передбачувано описує виклики;
13
+
- не перевантажує мережу;
14
+
- легко масштабується;
15
+
- не змушує вигадувати нестандартні “обхідні” рішення.
16
+
17
+
Саме тут Json-RPC часто дає кращий баланс.
18
+
19
+
## Де REST і GraphQL втрачають ефективність
20
+
21
+
### REST
22
+
23
+
REST добре інтегрується з HTTP і зручний для ресурсних сценаріїв. Але в складних системах він часто веде до:
24
+
25
+
- великої кількості запитів для однієї бізнес-операції;
26
+
- розмитих API-контрактів, коли потрібні не CRUD-дії, а команди;
27
+
- “зоопарку” реалізацій (різні дієслова, query/body/header-патерни, нестандартні підходи в командах).
28
+
29
+
У підсумку API стає складнішим у підтримці та гірше масштабується.
30
+
31
+
### GraphQL
32
+
33
+
GraphQL вирішує частину проблем REST: клієнт може отримувати саме ті поля, які потрібні. Але з’являються інші виклики:
34
+
35
+
- вища складність бекенду;
36
+
- складніші запити і складніший контроль навантаження;
37
+
- додаткові правила безпеки, кешування і лімітування.
38
+
39
+
Тобто GraphQL сильний інструмент, але не завжди найдешевший в експлуатації.
40
+
41
+
## Чому Json-RPC часто практичніший
42
+
43
+
Json-RPC розділяє транспорт і бізнес-логіку. API описується не “ресурсами”, а чіткими процедурами (method + params), які напряму відповідають бізнес-діям.
44
+
45
+
Це особливо корисно там, де API — це не “керування сутностями”, а набір команд і сценаріїв.
46
+
47
+
## Ключові переваги Json-RPC
48
+
49
+
### 1. Стандартизований формат запитів і відповідей
50
+
51
+
Кожен виклик має передбачувану структуру:
52
+
53
+
- `method` — назва процедури;
54
+
- `params` — вхідні параметри;
55
+
- `result` або `error` — стандартна відповідь.
56
+
57
+
Менше імпровізації в команді, простіші контракти, легше тестування.
58
+
59
+
### 2. Природна модель для бізнес-операцій
60
+
61
+
Якщо в системі багато дій на кшталт `calculatePrice`, `approveOrder`, `startWorkflow`, то Json-RPC дозволяє описати їх прямо, без штучного натягування на CRUD-модель.
62
+
63
+
### 3. Batch-запити
64
+
65
+
Json-RPC підтримує пакетні виклики, тому кілька операцій можна виконати в одному запиті. Це:
66
+
67
+
- зменшує кількість round-trip;
68
+
- скорочує мережеві витрати;
69
+
- прискорює інтеграцію складних сценаріїв.
70
+
71
+
### 4. Транспортна незалежність
72
+
73
+
Json-RPC не прив’язаний до одного транспорту: HTTP, WebSocket, TCP та інші варіанти можуть використовуватись залежно від задачі.
74
+
75
+
Це дає гнучкість при зміні архітектури без повного переписування API-контракту.
76
+
77
+
### 5. Краща масштабованість бізнес-логіки
78
+
79
+
Окремі процедури легко розширювати та версіонувати. Нові бізнес-функції додаються як нові методи, а не через ускладнення “ресурсних” схем.
80
+
81
+
## Коли що обирати
82
+
83
+
- **REST**: прості ресурсні API, де домінує CRUD.
84
+
- **GraphQL**: багато складних read-сценаріїв, де критичний контроль полів відповіді.
85
+
- **Json-RPC**: API з великою часткою командної бізнес-логіки, де важливі передбачуваність, пакетні виклики та гнучкість транспорту.
86
+
87
+
## Висновок
88
+
89
+
Json-RPC — недооцінений, але дуже сильний підхід для сучасних API. Він дозволяє будувати контракти ближче до бізнес-дій, зменшує технічний шум і спрощує розвиток системи в довгостроковій перспективі.
90
+
91
+
Для проєктів, де API — це не тільки CRUD, а насамперед бізнес-команди, Json-RPC часто є найбільш практичним вибором.