Требует ли архитектурный стиль REST физически отдельных клиентов и серверов?

Question

Требуется ли взаимодействие RESTful между физически отдельными клиентами и серверами? т.е. нужно ли взаимодействие каким-то образом включать сетевой стек? Есть ли какая-либо польза от использования HTTP-подобного «соглашения о вызовах» между различными компонентами приложения?

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

Например, в веб-приложении может быть полезно получить доступ («внутреннюю») информацию о пользователях через URL-адреса, такие как http://api.local/user/34 и «HTTP-клиент», который маршрутизирует и отправляет запросы внутри, а не через стандартную HTTP-маршрутизацию. и процесс отправки. Вместо предоставления обычной библиотеки и связанной документации разработчик пользовательского компонента предоставит конечные точки (ресурсы) URL, которыми можно манипулировать с помощью стандартных HTTP-глаголов. Поскольку разработчики уже знакомы с HTTP, потребуется меньше документации, и будет больше согласованности и единообразия между компонентами.

(Я думаю, что такое отношение к REST также помогает прояснить разницу между механизмами REST и RPC, такими как SOAP, - нет причин когда-либо использовать SOAP для «внутренних» вызовов, но понятное поведение и семантика REST могут привести к в некоторых ситуациях это полезно для «внутренних» вызовов. И, конечно, если вы используете REST для внутренних вызовов (уровень 0 REST?), тривиально преобразовывать такие взаимодействия во внешние вызовы, если возникает такая необходимость.)

Answer 1

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

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

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

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

получить эту вещь из этой службы, но только если ее ETag не "A", "B" или W / "C", поскольку это те, которые у меня есть в данный момент

Или

сохраните это здесь, но только если ETag W / "DEF" все еще действителен, так как это тег, который я использовал, когда делал свой GET только сейчас.

и

Я бы хотел найти такие виджеты, и результат должен быть предпочтительно в виде IAtomCollection, но вместо этого я возьму список ( Accept ). В прошлый раз, когда я задал этот вопрос, я получил ETag «foo» ( If-None-Match ), поэтому он мне не нужен, если он не изменился, но если вы не возражаете, Я хотел бы проверить правильность моего кэша на исходном сервере ( Cache-Control: must-revalidate ). Да, и кстати, здесь мои учетные данные ( Авторизация ).

Подобные вопросы очень легко выполнять в HTTP, и мы все знаем, как подделывать такие сложные запросы.

То же самое касается HTTP-ответов:

Привет, я нашел вашу коллекцию IAtomCollection и действительно проверил ее на сервере происхождения. То, что у вас есть, больше не действует, так что вот новое для вас. У него есть ETag «bar», и вы можете считать его свежим в течение двух минут без повторной проверки со мной, но если я уйду в следующий раз, когда вы спросите, вы можете продлить период свежести еще на одну минуту. И, конечно, ответ зависит от ваших полномочий (само собой разумеется?) И ваших предпочтений.

Опять старый добрый HTTP. Представьте себе возможность совершать вызовы методов, которые , умны!

Что касается HATEOAS, то если задуматься над инкапсулированием идентификаторов, это также позволит выполнить это ограничение. Но мои мысленные эксперименты не очень далеко пошли в этом направлении ...

Answer 2

Идеи, лежащие в основе REST, в значительной степени обусловлены экономикой передачи данных, удаленностью и нейтральностью архитектуры. Доступ к удаленному ресурсу дорог; Вам нужна архитектура, которая поощряет кешируемость, адресуемость и минималистическую семантику. Однако для внутрипроцессного взаимодействия отправка данных между подсистемами внутри системы является чрезвычайно дешевой и обычно сводится к передаче указателя, который удовлетворяет или устраняет все три цели.

Признаюсь, я не задумывался об этом глубоко, поэтому может возникнуть вопрос: как HTTP в процессе сделает мою жизнь проще?

Answer 3

В системе RESTful, которая выделяет ресурс, а не функцию, стоящую за ним, URI ресурса часто является наиболее естественным способом обращения к ресурсу.Это то, чем ресурс известен, так почему бы не использовать его?

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

В RESTx , мы учли это, предоставив вам как автору компонента очень простойозначает доступ к данным ресурса, размещенного на этом сервере.В то же время эта абстракция позволяет также ссылаться на данные, размещенные на других серверах, используя точно такой же синтаксис.Но вместо ручного HTTP-запроса вы вызываете метод accessCode(<uri>).Конечно, если uri ссылается на локальный ресурс, то фактического HTTP-запроса не будет, но вам не о чем беспокоиться. Вот пример того, как это выглядит .

Естественно, вам не нужно использовать встроенные URI в вашем коде.RESTx - это многократно используемый код, который настраивается по мере необходимости для создания нового ресурса RESTful.Поэтому часто URI, на которые вы ссылаетесь, являются частью конфигурации компонента.