REST против JSON-RPC?

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

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

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

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

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

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

    На стороне REST существует еще много отличий и преимуществ.

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

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

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

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

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

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

    Последнее, но не менее важное: использование HTTP в качестве протокола RPC представляет собой огромную ошибку в соответствии с конструктором HTTP 1.1 (и изобретателем REST): http://www.ics.uci.edu/~fielding/pubs/dissoration/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, заключается в том, что он следует ряду тщательно продуманных ограничений, обеспечивающих архитектурную гибкость. Эти ограничения include в себя обеспечение того, что клиент и сервер могут развиваться независимо друг от друга (вы можете вносить изменения без испорчения приложения своего клиента), вызовы не имеют состояния (состояние представлено через гипермедиа), для взаимодействия предусмотрен единый интерфейс, API разработан в многоуровневой системе, а ответ кэшируется клиентом. Существует также дополнительное ограничение для предоставления кода по требованию.

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

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

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

    Удачи, Майк

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

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

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

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

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

    (и извините за скобки)

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

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

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

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

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

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

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

    http://rpc.brutusin.org

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

    http://demo.rpc.brutusin.org

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

    Начо

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

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

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

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

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

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

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

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

    Почему JSON RPC:

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

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

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

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

    Почему REST:

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

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

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

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

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


    пример

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

    Когда вы работаете с 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}

    • ОТДЫХ Снятие с POST /Bank/Account/John/Transaction … аналогично.

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

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

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

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

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

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

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

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

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

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

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

    Было бы лучше выбрать 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 (обозначаемый как Object Object Notation), являющийся легким форматом обмена данными, легко для людей читать, а также писать. Для машин невозможно разобрать и генерировать. JSON – текстовый формат, который полностью независим от языка, но использует соглашения, которые знакомы программистам семейства языков, состоящим из C #, C, C ++, Java, Perl, JavaScript, Python и многих других. Такие свойства делают JSON идеальным языком обмена данными и лучшим выбором для выбора.

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

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

    Interesting Posts

    Проблемы с подключением к Интернету после установки Windows Phone 8 SDK

    Как получить предыдущий элемент в ng-repeat?

    Как изменить цвет фона кнопки WinAPI C ++

    Как обновить слайд PowerPoint при представлении

    MySQL – превратить таблицу в другую таблицу

    Часы Windows XP установлены неправильно после возобновления сна

    Как программно установить атрибут стиля в представлении

    JavaScript console.log вызывает ошибку: «Синхронный XMLHttpRequest в основном streamе устарел …»

    joda time – добавить будние дни на сегодняшний день

    Что необходимо учитывать при выполнении командного файла в качестве запланированной задачи?

    Кнопка в пользовательских Android Toast?

    Симулятор или эмулятор? В чем разница?

    Низкое качество изображения / изображения при захвате с камеры

    Как рисовать текст с помощью GLUT / OpenGL на C ++?

    Какой размер источника питания мне понадобится для компьютера с этими спецификациями?

    Давайте будем гением компьютера.