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

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

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

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

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

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

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

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

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

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

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

Во-первых, 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

Отличные ответы - просто хотел уточнить некоторые комментарии. 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% времени.

Удачи майк

ИМО, ключевым моментом является действие против ориентации на ресурсы. 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

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

Начо

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

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

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

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

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

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

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

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

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

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

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

Почему JSON RPC:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Было бы лучше выбрать 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 идеальным языком обмена данными и лучшим выбором.

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

Вы можете использовать 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 в пакете ответов.

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

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

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