代码之家  ›  专栏  ›  技术社区  ›  mjs

其余的体系结构样式是否需要物理上分离的客户机和服务器?

  •  3
  • mjs  · 技术社区  · 14 年前

    是否要求在物理上分离的客户机和服务器之间发生RESTful交互?即,交互是否需要以某种方式涉及网络堆栈?在应用程序的各个组件之间使用类似HTTP的“调用约定”有什么好处吗?

    在我看来,REST的好处,如它们,几乎同样适用于同一应用程序组件之间的通信,也适用于物理上独立的客户机和服务器之间的通信,而REST的好处 constraints and guiding principles 在不涉及网络堆栈的情况下可以满足。(我并不是说每个函数调用都要“看起来像HTTP”,但对于某些函数调用或交互,将交互视为HTTP可能是有意义的。)

    例如,在Web应用程序中,通过以下URL访问(“内部”)用户信息可能很有用 http://api.local/user/34 以及一个内部路由和发送请求的“HTTP客户机”,而不是通过一个标准的HTTP路由和发送过程。用户组件的开发人员不提供常规的库和相关文档,而是提供URL端点(资源),可以使用标准的HTTP谓词对其进行操作。由于开发人员已经熟悉HTTP,因此所需的文档更少,而且跨组件的一致性和一致性也更高。

    (我认为以这种方式考虑REST也有助于澄清REST和RPC机制(如SOAP)之间的区别——没有理由将SOAP用于“内部”调用,但是REST的理解行为和语义可能会使它在某些情况下对“内部”调用有用。当然,如果您使用rest进行内部调用(rest level 0?),如果需要,将这些交互转换为外部调用是很简单的。)

    3 回复  |  直到 14 年前
        1
  •  1
  •   mogsie    14 年前

    在进程中使用REST原则和HTTP语义 当然有道理 ,但可能只有当应用程序最终也是与HTTP通信的客户机或服务器时。

    最难的部分是尊重 分层约束 因为在层的另一个sie上调用singleton非常容易,因为它只是一个函数调用。

    但是,一个好处是您实际上可以将一个层从一个位置移动到另一个位置。很可能很难完全做到这一点,但我认为这是可行的,尽管我会冒险猜测这是从来没有做过的。

    在我自己的思想实验中,HTTP的所有好处都发挥了作用,仅仅是memcached或进程内缓存无法处理它。以缓存验证或条件放置为例。想象一下,能够以HTTP请求的表现性进行函数调用:

    从这个服务中检索这个东西,但前提是它的etag不是“a”或“b”或w/“c”,因为它们是我现在拥有的。

    把这个存储在这里,但只有当etag w/“def”仍然有效时,因为这是我刚才获取时使用的标记。

    我想搜索这样的小部件,最好把结果作为一个IAtomCollection,但我要一个列表来代替( 接受 )上次我问这个问题时,我得到了一个“foo”的etag。( 如果没有匹配 ,所以如果它没有改变,我不需要它,但是如果您不介意,我想用源服务器验证缓存的有效性。( 缓存控制:必须重新验证 )哦,顺便问一下,这是我的证件( 授权 )

    像这样的问题在HTTP中很容易解决,我们都知道如何伪造如此复杂的查询。

    HTTP响应也是如此:

    嗨,我找到了您的IAtomCollection,我确实用源服务器验证过它。你所拥有的东西不再有效,所以给你一个新的。它的etag是“bar”,你可以在不与我重新验证的情况下将其视为新鲜的两分钟,但是如果下次你问我时我不在,你可以将新鲜期延长一分钟。当然,你的回答会根据你的资历而有所不同(不言而喻,对吧?)以及你的喜好。

    同样,简单的旧HTTP。想象一下能够进行方法调用 那个 聪明!

    至于hateoas,在封装标识符中加入一些思想,也可以满足这个约束。但我的思想实验并没有朝这个方向发展太远…

        2
  •  1
  •   Marcelo Cantos    14 年前

    其余的想法主要是由数据传输、远程性和体系结构中立性的经济性驱动的。访问一个远程资源是昂贵的;您需要一个鼓励可缓存性、可寻址性和最低语义的体系结构。然而,对于进程内通信来说,在内部子系统之间发送数据非常便宜,通常相当于传递一个指针,这可以满足或排除所有三个目标。

    我承认我没有深入思考过这个问题,所以一个返回的问题可能是:进程内HTTP将如何使我的生活更容易?

        3
  •  0
  •   jbrendel    14 年前

    在一个强调资源而不是其背后功能的RESTful系统中,资源的URI通常是处理资源的最自然的方法。这就是资源所知道的,为什么不使用它呢?

    在某些系统中,并不总是清楚要执行哪些函数调用来获取资源提供的数据。同样,通过其URI(甚至从代码内部)对资源进行寻址可能是最方便的。

    RESTx 我们为您提供了一种非常简单的方法来访问托管在该服务器上的资源的数据,从而解决了这一问题。同时,这种抽象还可以使用完全相同的语法引用托管在其他服务器上的数据。但是不执行手动HTTP请求,而是调用 accessCode(<uri>) 方法。当然,如果URI引用本地资源,那么就不会有实际的HTTP请求,但这是您不必担心的事情。 Here is an example of what that looks like .

    当然,您不必在代码中使用硬连接的URI。RESTX是关于可重用代码的,为了创建新的RESTful资源,可以根据需要对代码进行配置。所以,通常您所指的URI是组件配置的一部分。