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

Question

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

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

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

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

Answer 1

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

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

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

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

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

Или

магазин это здесь, но только если ETag W/«DEF» остается в силе, так как это тег я когда Я сделал это сейчас.

и

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

Вопросы, подобные этим, настолько просты в использовании в HTTP, и все мы знаем, как создавать такие сложные запросы.

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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