Комментарии 5
Минусы:
Некоторых не устраивает наличие одного AP эндпоинта.
Нет нормального генератора API.
Каждый волен создавать свои кастомные ошибки. Из-за этого, переключаясь в другом проекте на JSON-RPC, будет тяжелее ориентироваться (условно, каждый придумывает свою ошибку 404) Думаю, это можно решить семантическими кодами.
JSON - человекочитаемый текстовый формат, некоторым нужны бинарные данные, что ускоряет передачу данных и позволяет повесить любую схему типов.
JSON-RPC может не подойти для очень сложных реквестов или респонсов, тут GraphQL выигрывает.
Еще - коммьюнити у JSON-RPC меньше, описанные выше минусы можно было бы исправить в JSON-RPC 3, но бигтеху это не надо, а свободное сообщество предпочло REST.
REST, это что-то про что спрашивают на собеседовании, а на деле каждый клепает свой REST, когда появляется не круд или фильтров настолько много, что они не влазит query-parameters. Поэтому лучше использовать что-то, что более-менее стандартизированно. Ибо под REST каждый понимает, что-то своё. Мало кто говорит про рест читал что-то в духе https://restfulapi.net/ Поэтому RPC/graphql лучше чем неразбериха с REST.
Большая часть указанных минусов вроде адресована в статье
Генератор API для вебсайтов с личным бэком (именно про такие я писал и сделал на это ссылку) не нужен. Для public API - возможно
Про передачу бинарных данных в статье есть. Объем трафика с компрессией потока будет примерно такой же. Да и не так часто это нужно делать - бинарники пересылать.
Про GraphQL не понял - что не может JSON-RPC по сравнению с GraphQL? Вопрос некорректный, потому что первое - формат передачи данных, второе - языка запросов, и через JSON-RPC можно передать какой угодно сложный SQL запрос с указанием как отформатировать на бэке результат перед возвратом. Но всё-таки?
Насчет комьюнити - у JSON есть комьюнити? Нету. Его просто используют, потому что это простой как валенок и настолько же удобный формат. Точно так же JSON-RPC - простой формат передачи данных, который просто нужно использовать. То, что я описал в статьях - не какие-то секреты и бест практики, это непосредственная выгода, которую сразу получаешь начиная использовать JSON-RPC. Единственный хинт - с переделкой эндпойнта
Комьюнити нужна сложным вещам, чтобы можно было зайти и поделиться своей болью или задать вопрос на который нет простого или однозначного решения - вот для REST-a нужна комьюнити
Но тут не соглашусь. Ещё в первой части статьи я обратил внимание, что вы категорически не согласны с тем, что GraphQL — это RPC. На мой взгляд — это именно так, а точнее — это RPC-based решение со своим языком запросов. То есть это следующий уровень абстракции в архитектуре. Разумеется, на базе RPC можно построить похожую штуку, чтобы предотвращать underfetching/overfetching. На базе RPC можно построить даже сам REST (но не наоборот).
Мы сейчас делаем более простой вариант — либо пишем отдельный метод, либо даём параметр типа "вернуть сокращённый набор данных", "вернуть полный набор данных". Ну, это упрощенно...
Если же прикрутить парсер query да ещё и резолверы, чтобы графовую структуру данных обслуживать... то RPC прерватится в GraphQL :)
Так что GraphQL в холиваре RPC vs REST на самом деле на нашей стороне :)
А вот что плохо — так это отсутствие хорошего фреймворка для nodejs, который реализует JSON-RPC с удобными слоями валидации на базе json-схем, проверки требования аутентификации и т.п. на основе конфигурации методов. Так, чтобы было декларативненько. Зато у REST есть NestJS (хотя и к нему есть прикрутки какие-то для использования JSON-RPC в контроллерах)
В итоге приходится писать свой велосипед. И оупенсорсить его пока рано :)
Круто! Рад видеть, что есть в сообществе понимание того, что REST переоценен и просто популярен.
Но! Очень часто критики начинают именно с того, что бросается в глаза — размазывание данных по HTTP-протоколу. Это не самое главное отличие. И оно как раз позитивно для публичных API именно из-за кэширования.
Но самое главное — этоя идея: существительные (сущности) против глаголов (функций).
Вот от этого и надо отталкиваться в разработке. Мне приходилось делать сложный краудсорсинговый проект — от REST там можно было бы кукшкой уехать, а с RPC получилось неплохо. Многие начинают пилить бэк на REST и скатываются в совсем не RESTful, а по сути в RPC со всеми минусами REST. Потом начинают тащить во спасение GraphQL, который по сути RPC+язык запросов.
Для меня самым серьезным минусом первого использования JSON-RPC был не самый удобный способ контроля запросов. Для REST подходит сетевой лог в devtools брайзера. А для JSON-RPC (особенно если эндпоинт один) — это неудобно. Ничего, решилось самописным экстеншеном (https://chromewebstore.google.com/detail/json-rpc-viewer/hnmcofcmhpllkdkncnofkjdlpieagngg)
Наконец, по поводу эндпоинтов — тут могут быть разные подходы. В недавнем проекте я использовал микросервисы и каждый — имеет свой RPC-модуль. При этом вполне можно выбрасывать каждый сервис наружу для фронта на отдельный эндпоинт, а внурь (на шину rabbitmq) — на отдельную очередь. Всё очень удобно.
Популяризация JSON-RPC (часть 2)