Зміни в документі Json-RPC vs REST & GraphQL

Остання зміна 2024/05/20 12:54 автором Ashterix
Від версії 1.2
редаговано Ashterix
дата 2024/05/12 02:00
Змінити коментар: Update document after refactoring.
До версії 1.3
редаговано Ashterix
дата 2024/05/12 02:31
Змінити коментар: Немає коментарів для цієї версії

Підсумок

Подробиці

Властивості сторінки
Назва
... ... @@ -1,1 +1,1 @@
1 -Json-RPC_vs_REST_&_GraphQL
1 +Json-RPC vs REST & GraphQL
Вміст
... ... @@ -2,10 +2,9 @@
2 2  (((
3 3  (% class="container" %)
4 4  (((
5 -= Чому JSON-RPC кращий за REST:
6 -мій погляд на сучасні API =
5 += Мій погляд на сучасні API =
7 7  
8 -Спробую тут викласти свою думку
7 +Спробую тут викласти свою думку і пояснити чому Json-RPC кращій вибір для побудови API
9 9  )))
10 10  )))
11 11  
... ... @@ -13,14 +13,20 @@
13 13  (((
14 14  (% class="col-xs-12 col-sm-8" %)
15 15  (((
16 -= Paragraph 1 =
15 +Сучасні технології передачі даних визначають темп розвитку багатьох галузей і способів ведення бізнесу. По мірі того, як компанії вимагають більшої швидкості, адаптивності та ефективності від своїх систем, також зростає потреба в передових методах розробки API. Одним з таких методів, який виокремлюється своєю ефективністю та гнучкістю, є JSON-RPC, метод, який часто недооцінюють на фоні більш популярних REST та GraphQL.
17 17  
18 -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.
17 +== Аналіз REST та GraphQL ==
19 19  
20 -== Sub-paragraph ==
19 +**REST**, який домінував у веб-розробці протягом останніх десятиліть, став популярним через свою зручність інтеграції з HTTP, але дуже часто він використовується за інерцією, просто через те, що розробник вже звик до нього і не помічає "костилів" які змушений робити з проєкта в проєкт щоб покрити вимоги бізнес-логіки. Невідворотньо по мірі росту складності додатків і зростання вимог до них, REST починає виявляти свою недостатність, оскільки цей підхід може вимагати численних запитів до сервера для виконання простих операцій та погано масштабується для складних систем.
21 21  
22 -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.
21 +**GraphQL** вирішує деякі з цих проблем, дозволяючи клієнтам визначати, які дані їм потрібні, в одному запиті. Проте цей метод також вносить власні виклики: складність реалізації на бекенді, зростання навантаження на сервер через складність запитів і потенційну неефективність використання ресурсів.
23 23  
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 +
24 24  == Sub-paragraph ==
25 25  
26 26  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.
... ... @@ -49,11 +49,5 @@
49 49  {{box title="**Contents**"}}
50 50  {{toc/}}
51 51  {{/box}}
52 -
53 -[[image:Templates.Article.Template.WebHome@image1.jpg]]
54 -//Figure 1: [[Sea>>https://commons.wikimedia.org/wiki/File:Isle_of_Icacos_II.jpg]]//
55 -
56 -[[image:Templates.Article.Template.WebHome@image2.jpg]]
57 -//Figure 2: [[Waves>>https://commons.wikimedia.org/wiki/File:Culebra_-_Playa_de_Flamenco.jpg]]//
58 58  )))
59 59  )))