REST против JSON-RPC?

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

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

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

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

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

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

Удачи, Mike

Ответ 5

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

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

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

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

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

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

Ответ 6

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

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

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

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

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

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

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

http://rpc.brutusin.org

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

http://demo.rpc.brutusin.org

Надеюсь, что это поможет спать!

Начо

Ответ 7

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

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

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

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

Ответ 8

Почему JSON RPC:

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

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

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

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

Почему REST:

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

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

Ответ 9

В соответствии с моделью зрелости Ричардсона вопрос не 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.

Ответ 10

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

Ответ 11

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

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

Ответ 12

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

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

"REST JSON-RPC" существует! REST с "лучшими практиками", для минимальной упаковки информации, с простыми и надежными контрактами.

Пример

(from этот ответ и дидактический контекст)

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

• 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}

• REST Снятие с POST /Bank/Account/John/Transaction... похоже.

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

Ответ 13

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

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

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

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

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

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

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

Ответ 14

Я думаю, что есть один момент, о котором люди забыли упомянуть. Если у вас уже есть веб-приложение, тогда REST желательно, так как вам понадобится сервер приложений в любом случае, и вы можете защитить оба с помощью https... но если у вас нет веб-приложения (просто есть приложение), тогда RPC желательно, так как вам больше не нужно настраивать сервер приложений и настраивать его, что является hastle. Кроме того, я не вижу никаких реальных основополагающих преимуществ.

Ответ 15

Было бы лучше выбрать 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/users) в HTTP. REST API зависит от нескольких HTTP-методов, таких как GET, PUT, POST, DELETE, PATCH. REST немного сложнее для неопытных разработчиков.

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

Ответ 16

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