ОТДЫХ против JSON-RPC? [закрыто]

251

Я пытаюсь выбрать между REST и JSON-RPC для разработки API для веб-приложения. Как они сравниваются?

Обновление 2015: я обнаружил, что REST проще в разработке и использовании для API, который обслуживается через Web / HTTP, потому что API-интерфейс может использовать существующий и зрелый протокол HTTP, понятный как клиенту, так и серверу. Например, коды ответов, заголовки, запросы, тела сообщений, кэширование и многие другие функции могут использоваться API без каких-либо дополнительных усилий или настроек.

Али Шакиба
источник
29
REST определенно является популярным ответом прямо сейчас. Я не уверен, что это всегда правильный ответ. Может быть несоответствие импеданса между ресурс-ориентированным API REST и проблемной областью, которая по своей сути основана на задачах или рабочих процессах. Если вы обнаружите, что вам приходится делать разные типы патчей для одного и того же ресурса или что определенные задачи не сопоставляются с конкретным ресурсом, тогда вы должны начать сгибать парадигму REST. Используете ли вы действия / команды в качестве ресурсов. Различаете ли вы типы команд в заголовке Content-Type как параметры? Не уверен, что есть универсальный ответ.
Лэндон Поч
27
JSON-RPC прост и непротиворечив, удобен в использовании.
Дне
1
В августе 2015 года я внедрил клиент и сервер с использованием REST, первые 2 дня учился, потом понял, почему он популярен. Было очень приятно, когда было создано маленькое приложение, у клиента действительно не было работы, чтобы запомнить различные пути URL, сервер на node.js и клиент в javascript имели одинаковую структуру (пути URL) для связи. Вот Это Да! это было очень быстро, продукт был доставлен всего за 15 дней, даже с нуля. Отдых это путь. Также обратите внимание, что Popular Apache CouchDB использует REST, отличную базу данных, и очень гордятся тем, что сделали это и в REST. Проще говоря, REST - ПРАВИЛЬНЫЙ (правильный) с чистым интерфейсом.
Манохар Редди Поредди
6
Это зависит от имеющихся у вас ограничений или вашей основной цели. Например, если производительность является основным аспектом, вам нужно выбрать JSON-RPC (например, высокопроизводительные вычисления). Если ваша основная цель - быть независимым, чтобы предоставить общий интерфейс для интерпретации другими людьми, ваш путь - ОТДЫХ. Если вы хотите обе цели, вы должны включить оба протокола. Ваши потребности определяют решение.
Статис Андроникос,
@StathisAndronikos Вы правы, моей главной целью было простота использования и хорошая производительность для веб-приложений (не HPC).
Али Шакиба

Ответы:

221

Основная проблема с RPC - связь. Клиенты RPC тесно связаны с реализацией сервиса несколькими способами, и становится очень трудно изменить реализацию сервиса, не нарушая клиентов:

  • Клиенты должны знать имена процедур;
  • Порядок параметров, порядок, типы и количество вопросов. Нелегко изменить сигнатуры процедур (количество аргументов, порядок аргументов, типы аргументов и т. Д.) На стороне сервера, не нарушая реализации клиента;
  • Стиль RPC не раскрывает ничего, кроме конечных точек процедуры + аргументов процедуры. Для клиента невозможно определить, что можно сделать дальше.

С другой стороны, в стиле REST очень легко направлять клиентов, включая управляющую информацию в представления (заголовки HTTP + представление). Например:

  • Можно (и фактически обязательно) вставлять ссылки, аннотированные типами отношений ссылок, которые передают значения этих URI;
  • Клиентские реализации не должны зависеть от конкретных имен процедур и аргументов. Вместо этого клиенты зависят от форматов сообщений. Это создает возможность использовать уже реализованные библиотеки для определенных медиаформатов (например, Atom, HTML, Collection + JSON, HAL и т. Д.)
  • Можно легко изменить URI, не нарушая клиентов, поскольку они зависят только от зарегистрированных (или специфичных для домена) отношений ссылок;
  • Можно встраивать подобные формы структуры в представления, давая клиентам возможность представить эти описания как возможности пользовательского интерфейса, если конечный пользователь - человек;
  • Поддержка кеширования является дополнительным преимуществом;
  • Стандартизированные коды состояния;

Есть много других отличий и преимуществ на стороне REST.

Иосеб
источник
20
Что вы подразумеваете под «обязательно вставлять ссылки, помеченные типами отношений ссылок, которые передают значения…»?
2013 года
129
«Клиенты должны знать имена процедур» - это не аргумент, поскольку в REST это имя жестко запрограммировано в URI, а не передается в качестве параметра. В противном случае сервер не будет знать, какой метод он должен выполнять.
Центурион
44
«Это не так легко изменить процедуры подписи ... на стороне сервера , не нарушая реализации клиента», это также является дискуссионным. И REST, и JSON-RPC не являются SOAP и не имеют WSDL, который описывает существующие веб-сервисы и их типы, чтобы их можно было использовать для динамических изменений на стороне клиента. Таким образом, в любом случае, если вы меняете веб-сервис, вам нужно сменить клиента. В противном случае вам нужно пойти с SOAP.
Центурион
64
Я закодировал множество приложений и пока не видел никаких гибких веб-сервисов. Если вы меняете бэкэнд и веб-сервисы, то клиент всегда нуждается в рефакторинге / обновлении, чтобы соответствовать новым требованиям. И я упомянул SOAP, и потому что он обладает чем-то гибким, например WSDL, вы можете что-то автоматизировать и иметь большую гибкость, потому что вы можете получить информацию о наборе результатов, типах данных и доступных веб-сервисах. REST и другие не имеют этого вообще. Таким образом, ни REST, ни JSON-RPC, ни другие типы веб-сервисов не дадут вам волшебства, которое устранит необходимость ручного обновления клиента.
Центурион
15
Для меня, моей нынешней команды и предыдущих команд, веб-сервисы RESTful предназначены для приложений типа CRUD. Относительно "Мы переписываем браузеры каждый раз, когда что-то меняется на сервере?" - нет, потому что браузеры являются просто исполнителями HTTP, они не имеют ничего общего с бизнес-логикой, которую должна реализовать клиентская программа (показывать экраны, выполнять связанные вещи). Похоже, что мы начали пламенную войну, но в целом я хотел бы иметь другой надежный источник для веб-сервисов RESTfull с практическим потоком использования, с волшебной гибкостью, на которую вы ссылаетесь. Между тем многие высказывания слишком расплывчаты.
Центурион
163

Я изучил проблему более подробно и решил, что чистый REST слишком ограничен, а RPC лучше, хотя большинство моих приложений - приложения CRUD. Если вы придерживаетесь REST, вы в конечном итоге будете ломать голову над вопросом, как легко добавить еще один необходимый метод в свой API для какой-то специальной цели. Во многих случаях единственный способ сделать это с помощью REST - создать для него еще один контроллер, что может чрезмерно усложнить вашу программу.

Если вы выбираете RPC, единственное отличие состоит в том, что вы явно указываете глагол как часть URI, что является четким, последовательным, менее ошибочным и действительно без проблем. Особенно, если вы создаете приложение, которое выходит за рамки простого CRUD, RPC - единственный путь. У меня есть еще одна проблема с пуристами RESTful: HTTP POST, GET, PUT, DELETE имеют определенные значения в HTTP, которые REST искажает смысл других вещей, просто потому, что они подходят большую часть времени - но не всегда.

В программировании я давно обнаружил, что попытка использовать одну вещь для обозначения двух вещей когда-нибудь придет и укусит вас. Мне нравится иметь возможность использовать POST практически для каждого действия, потому что оно дает свободу отправлять и получать данные, как ваш метод должен делать. Вы не можете вписать весь мир в CRUD.

Брюс Патин
источник
30
Этот ответ показывает слишком обычное заблуждение о том, что на самом деле представляет собой REST. REST - это не просто сопоставление CRUD и HTTP-методов. Идея о том, что это проблема «добавить другой метод», ясно указывает на то, что REST неправильно понимается как RPC поверх HTTP, а это совсем не так. Попробуйте прочитать блог Роя Филдинга или его диссертацию - Google поможет вам ее найти - вы совсем не описываете REST в своем ответе.
nepdev
68
Я очень практичный человек. Все описания REST, которые я прочитал, четко начинаются с сопоставления CRUD и HTTP-методов. Больше разрешено добавлять теоретически, но на практике нет. В качестве примера я недавно хотел реализовать PATCH для устройств Android, но обнаружил, что Android не разрешает PATCH, поэтому я использовал POST с явно определенным действием на этот счет в URI. По сути, чистый REST не выполняет те задачи, которые мне требуются, поэтому я использую то, что работает.
Брюс Патин
4
Итак, @BrucePatin, в вашей версии "REST" у вас есть контроллер с четырьмя открытыми методами, которые отображают от 1 до 1 с помощью GET | PUT | POST | DELETE? Некоторые фреймворки делают это, но это не REST. Глаголы HTTP делают смутные абстрактные утверждения о семантике данного запроса. Вы должны сопоставить свои конечные точки в эти классы соответствующим образом. GET может отображать множество разных конечных точек, как и другие. На самом деле нет причин, по которым вы не можете реализовать REST-ful JSON-RPC через HTTP.
Спинкус
5
Есть очень веская причина. Я мог бы хотеть несколько дюжин действий, и уже столкнулся с обычным использованием (Android), которое даже не поддерживает PATCH. Это убивает это холодно. Я предпочел бы быть последовательным, чем иметь дело с несколькими исключениями из правила. В общем, теперь я буду использовать только GET, POST и DELETE. PUT не учитывает отзывы, которые я хотел бы получить при обновлении. Я использую POST практически для всего. Что касается кеширования, оно вызвало много проблем с возвратом старых данных. Что касается помещения параметров в POST, ASP.NET уже обрабатывает их автоматически из автоматических объектов JSON.
Брюс Патин
22
Я считаю, что спор о том, чем на самом деле является REST, лишь подчеркивает ваши комментарии и подчеркивает серьезный недостаток REST. Концептуально сложно найти двух людей, которые полностью согласны с тем, что такое RESTful. В любом случае это не имеет значения, потому что ни один сервис не должен иметь недокументированный RPC или REST. Если это задокументировано, то у разработчика, который его использует, не должно быть проблем.
Проворный джедай
29

Во-первых, HTTP-REST - это архитектура «передачи состояния представления». Это подразумевает много интересного:

  • Ваш API не будет иметь состояния и, следовательно, будет намного проще разрабатывать (действительно легко забыть переход в сложном автомате) и интегрироваться с независимыми частями программного обеспечения.
  • Вы будете приведены к разработке методов чтения как безопасных , которые легко кэшировать и интегрировать.
  • Вы будете вести к разработке методов записи как идемпотентных , которые будут намного лучше справляться с таймаутами.

Во-вторых, HTTP-REST полностью совместим с HTTP (см. «Безопасный» и «идемпотентный» в предыдущей части), поэтому вы сможете повторно использовать библиотеки HTTP (существующие для каждого существующего языка) и обратные прокси-серверы HTTP, что даст вам возможность реализовать расширенные функции (кеш, аутентификация, сжатие, перенаправление, перезапись, ведение журнала и т. д.) с нулевой строкой кода.

И последнее, но не менее важное: использование HTTP в качестве протокола RPC является огромной ошибкой, по словам разработчика HTTP 1.1 (и изобретателя REST): http://www.ics.uci.edu/~fielding/pubs/dis Диссертация/ evaluation. HTM # sec_6_5_2

Орельен
источник
1
+1 за авторитетную ссылку «парень, который должен знать» .... После этого трудно поспорить за RPC через HTTP, не признавая его хаком /
обходным решением
9
Вы только что ссылались на что-то из 2000 года. Это скорее философский аргумент для REST, чем для RPC. Семантически и применяя шаблон RPC, вы можете легко считать URI «процедурой», а закодированные параметры… ну… параметрами. Любой шаблон будет отлично работать по HTTP. То же самое с SOAP, RAILS или любым другим количеством шаблонов / протоколов, которые были наложены на HTTP. Это не имеет значения, если вы предлагаете последовательный API, который не нарушает его контракт.
Проворный джедай
Аурелиен, не могли бы вы обосновать, почему REST проще интегрировать с независимыми частями программного обеспечения? Для меня, независимо от того, используете ли вы RESTful API или RPC, клиентское программное обеспечение должно знать формат, в котором говорит ваш API.
Алексей
1
@ Алексей Этот аргумент был связан с безгражданством. Это проще интегрировать кофеварку , чьи API является CREATE CUP, чем другой , который будет содержать INSERT COIN, SELECT COFFEE, SELECT SUGARи START. Во втором API, поскольку он зависит от состояния компьютера, вы должны быть очень осторожны с последовательностью вызовов процедур.
Орельен
1
HTTP в качестве протокола RPC является REST. Так что ваше неверное толкование шокирует наоборот.
Tiberiu-Ionuț Stan
24

Отличные ответы - просто хотел уточнить некоторые комментарии. JSON-RPC является быстрым и простым в использовании, но, как уже упоминалось, ресурсы и параметры тесно связаны, и он склонен полагаться на глаголы (api / deleteUser, api / addUser), используя GET / POST, где REST предоставляет слабосвязанные ресурсы (api / пользователи), который в HTTP REST API использует несколько методов HTTP (GET, POST, PUT, PATCH, DELETE). Неопытным разработчикам реализовать REST немного сложнее, но стиль стал довольно распространенным явлением в настоящее время, и он обеспечивает гораздо большую гибкость в долгосрочной перспективе (продлевая жизнь вашему API).

Наряду с отсутствием тесно связанных ресурсов, REST также позволяет вам избежать привязки к одному типу контента - это означает, что если вашему клиенту нужно получать данные в XML, JSON или даже YAML - если он встроен в вашу систему, вы можете верните любой из тех, кто использует заголовки content-type / accept.

Это позволяет вам поддерживать ваш API достаточно гибким для поддержки новых типов контента ИЛИ клиентских требований.

Но что действительно отличает REST от JSON-RPC, так это то, что он следует серии тщательно продуманных ограничений, обеспечивающих гибкость архитектуры. Эти ограничения включают в себя обеспечение того, чтобы клиент и сервер могли развиваться независимо друг от друга (вы можете вносить изменения, не портя приложение вашего клиента), вызовы не имеют состояния (состояние представлено через гипермедиа), для взаимодействий предусмотрен единый интерфейс, API разработан на многоуровневой системе, а ответ кэшируется клиентом. Существует также необязательное ограничение для предоставления кода по требованию.

Тем не менее, с учетом всего вышесказанного API-интерфейсы MOST не являются RESTful (согласно Филдингу), поскольку они не включают в себя гипермедиа (встроенные гипертекстовые ссылки в ответе, которые помогают перемещаться по API). Большинство API-интерфейсов, которые вы обнаружите, похожи на REST в том смысле, что они следуют большинству концепций REST, но игнорируют это ограничение. Однако все больше и больше API реализуют это, и это становится все более популярной практикой.

Это также дает вам некоторую гибкость, так как API, управляемые гипермедиа (например, Stormpath), направляют клиента к URI (то есть, если что-то меняется, в определенных случаях вы можете изменять URI без негативного влияния), где, как и в случае RPC, URI должны быть статичный. При использовании RPC вам также необходимо подробно документировать эти различные URI и объяснять, как они работают по отношению друг к другу.

В целом, я бы сказал, что REST - это путь, если вы хотите создать расширяемый, гибкий API, который будет долговечным. По этой причине, я бы сказал, что это путь 99% времени.

Удачи майк

Майк Стоу
источник
3
это не чуть-чуть сложнее, а, скорее, сложнее. Я пытался понять это в течение 4 месяцев или около того, и до сих пор не знаю, как написать сервис, который не превращается в RPC без состояния через http с использованием json, и я до сих пор не убежден есть реальная разница между "ОТДЫХОМ" и тем, что я только что сказал
Austin_Anderson
19

ИМО, ключевым моментом является действие против ориентации на ресурсы. REST ориентирован на ресурсы и хорошо подходит для операций CRUD, а его известная семантика обеспечивает некоторую предсказуемость для первого пользователя, но при реализации из методов или процедур вы вынуждены предоставлять искусственный перевод в мир, ориентированный на ресурсы. С другой стороны, RPC идеально подходит для API, ориентированных на действия, где вы предоставляете сервисы, а не наборы ресурсов с поддержкой CRUD.

Без сомнения, REST более популярен, это определенно добавляет некоторые моменты, если вы хотите представить API третьему лицу.

Если нет (например, в случае создания AJAX-интерфейса в SPA), мой выбор - RPC. В частности, JSON-RPC в сочетании со схемой JSON в качестве языка описания и переносится через HTTP или Websockets в зависимости от варианта использования.

JSON-RPC - это простая и элегантная спецификация, определяющая полезные нагрузки JSON запросов и ответов, которые будут использоваться в синхронном или асинхронном RPC.

Схема JSON - это черновая спецификация, определяющая основанный на JSON формат, предназначенный для описания данных JSON. Описывая входные и выходные сообщения службы с помощью схемы JSON, вы можете иметь произвольную сложность в структуре сообщений без ущерба для удобства использования, и интеграция служб может быть автоматизирована.

Выбор транспортного протокола (HTTP против веб-сокетов) зависит от различных факторов, и наиболее важным является то, нужны ли вам функции HTTP (кэширование, повторная проверка, безопасность, идемпотентность, тип контента, составная часть, ...) или необходимость обмена приложением сообщения на высоких частотах.

До сих пор это было мое личное мнение по этому вопросу, но теперь кое-что, что может быть действительно полезным для тех Java-разработчиков, читающих эти строки, фреймворк, над которым я работал в течение прошлого года, родившийся из того же вопроса, который вас интересует сейчас. :

http://rpc.brutusin.org

Вы можете увидеть живую демонстрацию здесь, показывающую встроенный браузер хранилища для функционального тестирования (спасибо JSON Schema) и ряд примеров сервисов:

http://demo.rpc.brutusin.org

Надеюсь, это помогает приятель!

Начо

idelvall
источник
Здорово найти родственного духа! Я работаю над чем-то похожим здесь: github.com/dnault/therapi-json-rpc
dnault
:) Я посмотрю на это
idelvall
1
Согласитесь с этим. REST хорошо работает для API CRUD, так как у вас есть очевидное POST / GET / PUT / DELETE [PoGPuD? ;)] картографирование. Тем не менее, если ваш API не подходит для этих глаголов, JSON-RPC может быть хорошим вариантом, так как глаголы просто будут путать. Так что да, кто его использует и почему это важный фактор.
Алджи Тейлор
1
Точно - REST - это царство существительных, JSON-RPC - это глаголы.
Роб Грант
16

Если ваш сервис работает нормально только с моделями и шаблоном GET / POST / PUT / DELETE, используйте чистый REST.

Я согласен, что HTTP изначально предназначен для приложений без сохранения состояния.

Но для современных, более сложных (!) Приложений реального времени (веб), где вы захотите использовать веб-сокеты (которые часто подразумевают отслеживание состояния), почему бы не использовать оба? JSON-RPC через Websockets очень прост, поэтому у вас есть следующие преимущества:

  • Мгновенные обновления на каждом клиенте (определите свой собственный RPC-вызов между серверами для обновления моделей)
  • Легко добавить сложности (попробуйте сделать клон Etherpad только с REST)
  • Если вы все сделаете правильно (добавьте RPC только в качестве дополнительного для реального времени), большинство из них по-прежнему будет использоваться только с REST (кроме случаев, когда основной функцией является чат или что-то еще)

Поскольку вы разрабатываете только API на стороне сервера, начните с определения моделей REST, а затем добавьте поддержку JSON-RPC по мере необходимости, сводя количество вызовов RPC к минимуму.

(и извините за чрезмерное использование скобок)

cbix
источник
15

В прошлом я был большим поклонником REST, и у него было много преимуществ перед RPC на бумаге. Вы можете предоставить клиенту различные типы контента, кеширование, повторное использование кодов состояния HTTP, вы можете направлять клиента через API и встраивать документацию в API, если она в основном не требует объяснений.

Но мой опыт показывает, что на практике это не так, и вместо этого вы выполняете много ненужной работы, чтобы все сделать правильно. Кроме того, коды состояния HTTP часто не соответствуют вашей логике домена, и использование их в вашем контексте часто кажется немного вынужденным. Но самое плохое в REST, на мой взгляд, это то, что вы тратите много времени на разработку своих ресурсов и взаимодействий, которые они позволяют. И всякий раз, когда вы делаете какие-то важные дополнения к своему API, вы надеетесь, что найдете хорошее решение для добавления новой функциональности, и вы уже не загнали себя в угол.

Мне часто кажется, что это пустая трата времени, потому что большую часть времени у меня уже есть прекрасное и очевидное представление о том, как моделировать API как набор удаленных вызовов процедур. И если я приложил все усилия, чтобы смоделировать свою проблему в рамках ограничений REST, то следующая проблема - как вызвать ее у клиента? Наши программы основаны на процедурах вызова, поэтому создание хорошей клиентской библиотеки RPC легко, создание хорошей клиентской библиотеки REST не так уж и много, и в большинстве случаев вы просто отобразите свой API-интерфейс REST на сервере на набор процедур вашего клиента. библиотека.

Из-за этого RPC сегодня кажется мне намного проще и естественнее. Что мне действительно не хватает, так это последовательная структура, которая позволяет легко создавать RPC-сервисы с самоописанием и возможностью взаимодействия. Поэтому я создал свой собственный проект, чтобы поэкспериментировать с новыми способами упростить RPC для себя, и, возможно, кто-то найдет его полезным: https://github.com/aheck/reflectrpc

АЭХ
источник
Проверьте OpenRPC, он должен решить вашу потребность в «простых в написании RPC-сервисах, которые самоописываются и могут взаимодействовать»
Belfordz
12

Согласно модели зрелости Ричардсона , вопрос не в REST или RPC , а в том, сколько REST ?

С этой точки зрения соответствие стандарту REST можно классифицировать по 4 уровням.

  • Уровень 0: мыслить с точки зрения действий и параметров. Как объясняется в статье, это по сути эквивалентно JSON-RPC (в статье объясняется это для XML-RPC, но одинаковые аргументы справедливы для обоих).
  • Уровень 1: мыслите с точки зрения ресурсов. Все, что относится к ресурсу, принадлежит одному URL
  • уровень 2: использовать HTTP-глаголы
  • уровень 3: HATEOAS

По словам создателя стандарта REST, только сервисы уровня 3 могут называться RESTful. Однако это показатель соответствия , а не качества. Если вы просто хотите вызвать удаленную функцию, которая выполняет вычисления, вероятно, не имеет смысла иметь в ответе соответствующие гиперссылки, а также дифференцирование поведения на основе используемого глагола HTTP. Таким образом, такой вызов по своей природе имеет тенденцию быть более RPC-подобным. Тем не менее, более низкий уровень соответствия не обязательно означает состояние или более высокую степень связи. Возможно, вместо того, чтобы думать о REST или RPC , вы должны использовать как можно больше REST, но не более. Не перекручивайте свое приложение только для соответствия стандартам соответствия RESTful.

blue_note
источник
1
+1 для уровней 0, 1 и 2. Однако я никогда не видел успешной реализации HATEOS, но видел две неудачные попытки.
MJHM
8

Почему JSON RPC:

В случае API REST, мы должны определить контроллер для каждой функциональности / метода, который нам может понадобиться. В результате, если у нас есть 10 методов, которые мы хотим сделать доступными для клиента, мы должны написать 10 контроллеров, чтобы связать запрос клиента с конкретным методом.

Другим фактором является то, что, хотя у нас есть разные контроллеры для каждого метода / функциональности, клиент должен помнить, использовать ли POST или GET. Это еще более усложняет ситуацию. Кроме того, для отправки данных необходимо установить тип содержимого запроса, если используется POST.

В случае JSON RPC все значительно упрощается, поскольку большинство серверов JSONRPC работают с методами POST HTTP, а тип контента всегда равен application / json. Это избавляет от необходимости запоминать использование правильного метода HTTP и настроек контента на стороне клиента.

Не нужно создавать отдельные контроллеры для различных методов / функций, которые сервер хочет предоставить клиенту.

Почему ОТДЫХ:

У вас есть отдельные URL для разных функций, которые сервер хочет предоставить клиентской стороне. В результате вы можете встраивать эти URL.

Большинство из этих пунктов являются дискуссионными и полностью зависят от потребностей человека.

Умер Фарук
источник
3

Я думаю, как всегда, это зависит ...

REST обладает огромным преимуществом широкой общественной поддержки, а это означает множество инструментов и книг. Если вам нужно создать API, который используется большим количеством потребителей из разных организаций, то это путь только по одной причине: он популярен. В качестве протокола это, конечно, полный провал, поскольку существует слишком много совершенно разных способов сопоставления команды с URL / глаголом / ответом.

Поэтому, когда вы пишете одностраничное веб-приложение, которое должно взаимодействовать с бэкэндом, я думаю, что REST слишком сложен. В этой ситуации вам не нужно беспокоиться о долгосрочной совместимости, поскольку приложение и API могут развиваться вместе.

Однажды я начал с REST для одностраничного веб-приложения, но мелкозернистые команды между веб-приложением и сервером быстро свели меня с ума. Должен ли я кодировать его как параметр пути? В организме? Параметр запроса? Заголовок? После разработки URL / глагола / ответа мне пришлось кодировать этот беспорядок в Javascript, декодере на Java, а затем вызывать реальный метод. Несмотря на то, что для этого есть много инструментов, очень сложно не получить какую-либо семантику HTTP в коде вашего домена, что является очень плохой практикой. (Сплоченность)

Попробуйте создать файл Swagger / OpenAPI для сайта средней сложности и сравните его с одним интерфейсом Java, который описывает удаленные процедуры в этом файле. Увеличение сложности ошеломляет.

Поэтому я переключился с REST на JSON-RPC для одностраничного веб-приложения. Я разработал крошечную библиотеку, которая кодировала интерфейс Java на сервере и отправила ее в браузер. В браузере это создало прокси для кода приложения, которое возвращало обещание для каждой функции.

Опять же, REST имеет свое место только потому, что он известен и поэтому хорошо поддерживается. Также важно признать основную философию ресурсов без учета состояния и иерархическую модель. Тем не менее, эти принципы можно так же легко использовать в модели RPC. JSON RPC работает через HTTP, поэтому он имеет те же преимущества REST в этой области. Разница в том, что когда вы неизбежно сталкиваетесь с этими функциями, которые плохо соответствуют этим принципам, вы не обязаны выполнять много ненужной работы.

Питер Криенс
источник
1
Этот ответ заставил меня осознать сходство между GraphQL и JSON-RPC и почему GraphQL становится популярным выбором для SPA.
Денис
OpenRPC является эквивалентом OpenAPI / Swagger, но для JSON-RPC
Belfordz
1

REST тесно связан с HTTP, поэтому, если вы предоставляете свой API только через HTTP, тогда REST больше подходит для большинства (но не для всех) ситуаций. Однако, если вам нужно представить свой API поверх других транспортов, таких как обмен сообщениями или веб-сокеты, тогда REST просто не применим.

dtoux
источник
2
REST - это архитектурный стиль, не зависящий от протокола.
Марк Сидаде
4
Вы правы ОТДЫХ это архитектурный принцип. Тем не менее, его теоретическая основа находилась под сильным влиянием протокола HTTP и, несмотря на утверждение универсальной применимости, не нашла практического применения за пределами веб-домена. Таким образом, можно с уверенностью сказать, что когда кто-то упоминает REST, он ссылается на веб-сервисы, а не на архитектурный принцип.
dtoux
1

Было бы лучше выбрать JSON-RPC между REST и JSON-RPC для разработки API-интерфейса для веб-приложения, которое будет легче понять. JSON-RPC является предпочтительным, поскольку его сопоставление с вызовами методов и связями может быть легко понято.

Выбор наиболее подходящего подхода зависит от ограничений или основной цели. Например, поскольку производительность является основной характеристикой, рекомендуется использовать JSON-RPC (например, высокопроизводительные вычисления). Тем не менее, если основная цель заключается в том, чтобы быть независимым, чтобы предложить общий интерфейс, который могут быть выведены другими, рекомендуется перейти на REST. Если вам необходимо достичь обеих целей, желательно включить оба протокола.

Факт, который на самом деле отделяет REST от JSON-RPC, заключается в том, что он содержит ряд тщательно продуманных ограничений, подтверждающих гибкость архитектуры. Ограничения заключаются в том, чтобы гарантировать, что клиент и сервер могут расти независимо друг от друга (изменения могут быть внесены без вмешательства в приложение клиента), вызовы не имеют состояния (состояние рассматривается как гипермедиа), единообразны интерфейс предлагается для взаимодействия, API продвигается на многоуровневой системе (Hall, 2010). JSON-RPC является быстрым и простым в использовании, однако, поскольку упомянутые ресурсы и параметры тесно связаны между собой, и он, вероятно, будет зависеть от глаголов (api / addUser, api / deleteUser), использующих GET / POST, тогда как REST предоставляет слабосвязанные ресурсы (api / пользователи) в HTTP. API REST зависит от нескольких методов HTTP, таких как GET, PUT, POST, DELETE, PATCH.

JSON (обозначаемый как JavaScript Object Notation) - это легкий формат обмена данными, который легко читать и писать людям. Это беспрепятственно для машин для анализа и генерации. JSON - это текстовый формат, который полностью независим от языка, но использует соглашения, знакомые программистам из семейства языков, состоящего из C #, C, C ++, Java, Perl, JavaScript, Python и многих других. Такие свойства делают JSON идеальным языком обмена данными и лучшим выбором.

SinghKunal
источник
«Машины бесполезны для анализа», - я видел много сломанных JSON (например, неэкранированные кавычки в полезной нагрузке)
alancalvitti
1

Неправильный вопрос: накладывает манихейство, которого не существует!

Вы можете использовать JSON-RPC с «менее глаголом» (без метода ) и сохранить минимальную стандартизацию, необходимую для идентификатора отправки, параметров, кодов ошибок и предупреждающих сообщений. Стандарт JSON-RPC не говорит «вы не можете быть ОТДЫХОМ», а только говорит, как упаковать основную информацию.

"REST JSON-RPC" существует ! ОТДЫХ с «передовой практикой», для минимальной упаковки информации, с простыми и солидными контрактами.


пример

(из этого ответа и дидактического контекста)

Когда речь идет о REST, это обычно помогает начать с мышления с точки зрения ресурсов. В этом случае ресурс - это не просто «банковский счет», а транзакция этого банковского счета ... Но JSON-RPC не обязывает параметр «method», все они закодированы как «путь» конечной точки.

  • REST Депозит с POST /Bank/Account/John/Transactionпомощью запроса JSON {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
    Ответ JSON может быть чем-то вроде{"jsonrpc": "2.0", "result": "sucess", "id": 12}

  • ОТДЫХ Выйти с POST /Bank/Account/John/Transaction... похоже.

  • ... GET /Bank/Account/John/Transaction/12345@13... Это может вернуть JSON-запись этой конкретной транзакции (например, ваши пользователи обычно хотят получить записи о дебетах и ​​кредитах в своей учетной записи). Что-то как {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Соглашение о (REST) ​​GET-запросе может включать кодирование id с помощью «@id», поэтому не нужно отправлять какой-либо JSON, но все же использовать JSON-RPC в пакете ответов.

Питер Краусс
источник
См. Также stackoverflow.com/a/13952665/287948
Питер Краусс
0

Если вы запрашиваете ресурсы, то RESTful API лучше по дизайну. Если вы запрашиваете некоторые сложные данные с большим количеством параметров и сложных методов, кроме простого CRUD, то RPC - верный путь.

Адриан Лю
источник
Это очень большое упрощение темы. Почему именно «лучше по замыслу»? JSON-RPC может быть настолько простым или сложным, насколько вы хотите, и поэтому аргумент о том, что он «лучше» для «большого количества параметров и сложных методов», также неверен. В этом вопросе не лучше и не хуже.
Белфордц
Не имеет значения, использует ли RPC JSON, protobuf или XML для сериализации данных. Ключевым моментом является API, как я уже сказал. Я не имею в виду, что одно лучше другого во всех случаях. Но я думаю, что параметры и методы имеют значение, когда вы выбираете между двумя реализациями. Если они просты, большинство программистов хорошо понимают RESTful API, и вы можете легко создать запрос http. Если они сложные, RPC более способен выражать такие API, и ваша IDE и компилятор могут помочь вам в этом.
Адриан Лю
-1

Я использую vdata для протокола RPC: http://vdata.dekuan.org/

1, PHP и JavaScript оба в порядке. 2, вызов совместного использования ресурсов (CORS) все еще в порядке.

Лю Цисин
источник