是否要求在物理上独立的客户端和服务器之间进行RESTful交互?即交互是否需要以某种方式涉及网络堆栈?在应用程序的各个组件之间使用类似HTTP的“调用约定”有什么好处吗?
在我看来,REST的好处,例如它们,几乎同样适用于同一应用程序的组件之间的通信,以及物理上独立的客户端和服务器之间的通信,以及REST的constraints and guiding principles可以是在没有涉及网络堆栈的情况下满意。 (我并不是说每个函数调用“看起来像HTTP”都是一个好主意,但对于某些函数调用或交互,它可能有助于交互类似HTTP。)
例如,在Web应用程序中,通过诸如http://api.local/user/34
之类的URL和“HTTP客户端”访问(“内部”)用户信息可能是有用的,这些URL在内部路由和分派请求,而不是通过标准HTTP路由和调度过程。用户组件的开发人员不提供传统的库和相关文档,而是提供URL端点(资源),可以使用标准HTTP谓词进行操作。由于开发人员已经熟悉HTTP,因此需要的文档较少,并且组件之间的一致性和一致性会更高。
(我认为以这种方式思考REST也有助于澄清REST和RPC机制之间的区别,比如SOAP - 没有理由将SOAP用于“内部”调用,但REST的理解行为和语义可能会使在某些情况下,它对“内部”调用很有用。当然,如果你使用REST进行内部调用(REST Level 0?),如果需要,将这些交互转换为外部调用是很容易的。)
答案 0 :(得分:1)
REST背后的思想很大程度上取决于数据传输的经济性,远程性和架构中立性。访问远程资源很昂贵;你想要一个鼓励可缓存性,可寻址性和简约语义的架构。但是,对于进程内通信,在子系统之间发送数据非常便宜,通常相当于传递指针,这满足或消除了所有三个目标。
我承认我没有深入思考这个问题,所以回归问题可能是有道理的:进程中的HTTP如何让我的生活变得更轻松?
答案 1 :(得分:1)
在进程中使用REST原则和HTTP语义肯定有意义,但可能只有当您的应用程序最终也是与HTTP通信的客户端或服务器时。
困难的部分是尊重HTTP的分层约束,因为它很容易在图层的另一个sie上调用该单例,因为它只是一个函数调用。
然而,一个好处是,您实际上可以将图层从一个地方移动到另一个地方。可能很难完全实现这一点,但我认为这是可行的,尽管我猜测它从未被完成。在我自己的想法实验中,HTTP的所有好处都发挥作用,仅仅是memcached或进程内缓存无法处理它的方式。以缓存验证或条件放置为例。想象一下,能够通过HTTP请求的表达来进行函数调用:
从此服务中检索此内容,但仅当其ETag不是“A”或“B”或W /“C”时,因为这些是我现在拥有的那些
或者
将此存储在此处,但仅当ETag W /“DEF”仍然有效时,因为这是我刚刚完成GET时使用的标记。
和
我想搜索这样的小部件,并将结果优选地作为IAtomCollection,但我将改为使用List(接受)。我最后一次问这个问题时,得到了一个“foo”的ETag( If-None-Match ),所以如果没有改变我就不需要它,但是如果你没有我想用原始服务器验证缓存的有效性(缓存控制:必须重新验证)。哦,顺便说一下,这是我的凭据(授权)。
这些问题在HTTP中很容易实现,我们都知道如何伪造这些复杂的查询。
HTTP响应也是如此:
嗨,我找到了你的IAtomCollection,我确实用原始服务器验证了它。你拥有的东西不再有效,所以这里有一个新的。它有“酒吧”的ETag,你可以考虑新鲜两分钟而不与我重新验证,但如果我下次再问你,你可以将新鲜期延长一分钟。当然,响应会根据您的凭据(不用说,对吗?)和您的偏好而有所不同。
再次,普通的旧HTTP。想象一下,能够进行 智能的方法调用!
至于HATEOAS,对封装标识符进行一些考虑会使得尊重该约束成为可能。但是我的思想实验并没有走向这个方向......
答案 2 :(得分:0)
在强调资源而不是其背后的功能的RESTful系统中,资源的URI通常是解决资源的最自然方式。这就是资源所知的,为什么不使用呢?
在某些系统中,并不总是清楚要执行哪些函数调用以获取资源提供的数据。再次,简单地通过其URI(甚至在代码中)寻址资源可能是最方便的。
在RESTx中,我们通过为您提供一个非常简单的方法来访问此服务器上托管的资源的数据,从而满足了这一需求。同时,这种抽象使得使用完全相同的语法引用托管在其他服务器上的数据也成为可能。但是,不是执行手动HTTP请求,而是调用accessCode(<uri>)
方法。当然,如果uri引用本地资源,那么就不会有实际的HTTP请求,但这是您不必担心的事情。 Here is an example of what that looks like
当然,您不必在代码中使用硬连线URI。 RESTx是关于可重用代码的,可根据需要进行配置以创建新的RESTful资源。因此,您所指的URI通常是组件配置的一部分。