REST是否仅适用于具有人机交互的应用程序？

Question

对于使用RESTful架构构建应用程序，我还是个新手。事实上，到目前为止，我所做的一切都被伦纳德·理查森归类为Level 2 REST，我知道菲尔丁会将happily categorize归类为非RESTful。

我花了几个小时试图理解HATEOAS和如何达到4级。现在我看得更清楚了。我将应用程序概念化为一系列状态转换，资源将动态提供有关如何从一个状态转换到另一个状态的信息的链接。

但与HATEOAS相关的一切似乎都是人机交互所固有的。我的意思是，即使资源提供了使应用程序用户能够移动到下一个状态的链接，最终也是用户通过使用所提供的链接将应用程序从一个状态驱动到另一个状态。

但是，当我们处理计算机对计算机的交互时，事情应该如何工作呢？毕竟，当涉及到面向服务时，服务组合的想法是关键，我们不能天真地假设客户端总是一个人？许多服务被设计为供非人类用户使用，并且一些交互/编排可能相当复杂，通常使用BPM或BPEL之类的东西进行建模。

REST和特别是HATEOAS是否只适用于需要人工干预的应用程序?如果不是，它应该如何工作？

我有一种感觉，REST只对某些类型的解决方案有好处，对于其他类型的解决方案是不够的，但是现有的文献未能解释这些不足之处，并将REST作为万恶之药来推销，但我就是不太明白如何在人类不是驱动程序的情况下使用适当的服务组合。

我真的很感激任何关于这方面的参考或见解，因为相信我，我有两天的时间连续阅读我所能找到的关于这个话题的所有内容，但我还没有能够得出任何合理的和有充分记录的结论。

Answer 1

那么，您的客户端应用程序可以解析响应以获取可能的操作。在这种情况下，实际的urls不是从API的知识中获得的，而是在调用初始方法(通常是GET)时获得的。都是没有人类的。

Answer 2

这听起来就像是您将SOA与REST/Hypermedia进行比较，而没有看到SOA是一种策略，用于设计由其他系统组成的复杂系统，而REST/Hypermedia是一种软件体系结构风格，对客户端-服务器通信应用了一系列约束。然而，客户端既可以是服务器，也可以是人，这都无关紧要。

在勾勒/设计服务组合时，使用或不使用REST/超媒体不是一件麻烦的事情。在尝试实现语法互操作性时，这是一个很重要的问题。很多时候，这归结为将REST与Soap和其他技术细节进行比较。