RESTful Web 服务是重用基础设施的正确方法吗？
我发现使用 Web API（RESTful 服务）访问远程基础设施存在争议。如果您能发表评论，我将不胜感激。来自文章“RESTful Web 服务与“大型”Web 服务：做出正确的架构决策”[1] 的建议是使用 Web API，而不是进行即席集成（a la' mashup）和快速原型制作。 [2]中进行的实证研究表明，在重用现有信息和功能的场景中遵循这些建议。然而，通过 Web API 重用基础设施并不适合临时集成的任务。我的印象是，基础设施通常在我拥有的资源无法很好地扩展以解决我想要解决的问题的情况下被重用：大量数据、高带宽、高并发。尽管如此，Amazon 通过以下方式提供对其基础设施（存储空间、消息队列）的远程访问：
- 经典 SOAP Web 服务（所谓的 Big Web 服务）和
- 轻型 RESTful Web 服务（所谓的 Web API）。
尽管没有任何文字说明客户端（在 Amazon Web Services 的案例研究中进行了描述）是否使用大型 Web 服务或 Web API，但 Amazon 以 Web API 的形式提供对其基础设施的访问作为替代方案这一事实必定是有意义的。
你知道他们的动机是什么吗？您是否知道人们为了快速原型设计而重复使用基础设施的情况？或者也许是为了测试？换句话说，如果我想重用 Amazon 提供的基础设施，在什么示例情况下我应该使用 SOAP 或 REST 哪种 API 风格？
编辑：在这种情况下，我的意思是作为基础设施：存储空间，计算能力、互联网带宽。因此我想知道这些资源是否在临时集成中被重用。
Cesare Pautasso、Olaf Zimmermann、Frank Leymann，RESTful Web 服务与“大型”Web 服务：做出正确的架构决策，第 805-814 页，Jinpeng Huai、Robin Chen、Hsiao- Wuen Hon、刘云浩、马伟英、Andrew Tomkins、张晓东（主编），第 17 届国际万维网会议论文集，ACM 出版社，中国北京，2008 年 4 月。 Cesare Pautasso
哈特曼、比约恩和斯科特·多利Klemmer，Scott R.，黑客、混搭、粘合：了解机会主义设计，IEEE 普适计算，卷。 7、没有。 3, 46-54 (2008)。
There is one controversy I see in using Web APIs (RESTful service) to access remote infrastracture. I would be grateful, if you could comment it. The recommendation coming from the article "RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision" [1] is to use Web APIs rather for ad hoc integration (a la' mashup) and rapid prototyping. Empirical studies made in [2] shows these recommendation is followed in scenarious of re-using the existing information and functionality. However, re-using infrastructure with Web APIs does not fit well into the task of ad hoc integration. My impression is rather that infrastructure is usually re-used in scenarios where the resources I have do not scale well for the problem that I want to solve: large number of data, high bandwidth, high concurrency. Nevertheless, Amazon provides remote access to their infrastructure (storage space, message queueuing) both through:
- classical SOAP Web services (so called Big Web services) and
- light RESTful Web services (so called Web APIs).
Although there is nothing written whether the clients (described in case studies of Amazon Web Services) employ Big Web services or Web APIs, the fact that Amazon provides access to their infrastracture in form of Web APIs as an alternative must be meaningful.
Do you know what can be their motivation? Do you know any cases where people re-used infrastracture just for rapid prototyping? Or maybe for testing? In other words, if I would like to re-use infrastructure offered by the Amazon, which API style should I use SOAP or REST in what example situations?
EDIT: In this case as an infrastructure I meant: storage space, computational power, internet bandwidth. Thus I wonder whether such resources are re-used in ad hoc integration.
Cesare Pautasso, Olaf Zimmermann, Frank Leymann, RESTful Web Services vs. "Big" Web Services: Making the Right Architectural Decision, pp. 805-814, Jinpeng Huai, Robin Chen, Hsiao-Wuen Hon, Yunhao Liu, Wei-Ying Ma, Andrew Tomkins, Xiaodong Zhang (Ed.), Proceedings of the 17th International World Wide Web Conference, ACM Press, Beijing, China, April 2008.
Hartmann, Bjorn & Doorley, Scott & Klemmer, Scott R., Hacking, Mashing, Gluing: Understanding Opportunistic Design, IEEE Pervasive Computing , vol. 7, no. 3, 46-54 (2008).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
了解使用哪个版本的关键在于了解一件事 - 如果您需要通过深度嵌入的对象层次结构在 Web 上执行复杂的操作，那么您实际上被迫使用 Web 服务。 REST 在执行简单操作时非常有能力，但复杂的操作超出了它的范围。
我通常喜欢将 RESTful 系统设想为只需通过浏览器命令栏调用命令即可测试的系统。 RESTful 应用程序确实很容易测试，并且通常非常适合通过模拟进行测试。
The key to understanding which version to use lies in understanding one thing - if you need to perform complicated operations over the web with deeply embedded object hierarchies, then you are effectively forced into using web services. REST is exceptionally capable when it comes to performing simple operations, but complex operations break outside its remit.
I typically like to envisage RESTful systems as being ones which I can test just by invoking a command through the browser command bar. RESTful applications are really easy to test, and are generally very suitable for testing via mocking.
我认为，当人们谈论利用 RESTful Web 服务来利用现有基础设施时，他们的意思是他们可以使用为 Web 设计的现有东西，而不必使用专门为 Web 服务构建的软件。例如，如果我有一个使用 REST 的 Web 服务，我可以利用 HTTP 缓存代理之类的东西，而要在哪里获得与 SOAP 相同的功能，我需要一些专门的东西。
I think when people talk about leveraging existing infrastructure with RESTful web services they mean they can use existing things designed for the web rather than having to use software specifically built for web services. For instance if I have a web service using REST I can take advantage of things like HTTP caching proxies, where to get the equivalent functionality with SOAP I would need something specialized.
REST 比 SOAP 更容易使用。 FWIW，Google 不再使用 SOAP，一切都是 REST。
SOAP 的唯一优点是您可以立即使用对象。使用 REST，您要么需要一个框架（如 JAX-RS）来为您创建这些对象，要么手动解析它们。
REST 的另一个巨大优势是您实际上可以在访问日志中看到请求。大多数 SOAP 请求 POST 到完全相同的端点，因此很难确定您想要执行的操作。另一方面，REST 通常会发布到特定的端点，因此您实际上可以从网络浏览器中访问它们，而无需使用精美的应用程序。
REST is infinitely easier to use than SOAP. FWIW, Google doesn't use SOAP anymore, it's all REST.
The only advantage to SOAP is that you get objects to use right out of the box. With REST, you either need a framework, like JAX-RS, to create these objects for you, or parse them manually.
Another huge advantage of REST, is you can actually see the requests in your access logs. Most SOAP requests POST to the exact same endpoint, so it's a ton harder to determine what you were trying to do. On the other hand, REST typically posts to specific endpoints, so you can actually hit them from your web-browser w/o the need of a fancy app.