language-agnostic - 选择 Web 服务的方法

Question

我被要求建立一个新的网络服务，该服务应该可以在任何可能的语言(php、.NET、Java 等)中轻松使用。当然，可以自己滚动，接受不同的内容类型(xml/x-www-form-urlencoded(普通帖子)/json/等)，但现有的方法或机制当然是首选，可以减少时间花费在服务消费者的开发上。

网络服务确实接受修改/设置(这不仅仅是简单的数据检索)，但这些修改/设置很可能会比获取少很多(我们估计大约 2.5% 的设置，97.5 次获取)。这里的术语 Webservice 表示协议(protocol)应该通过 HTTP，不能完全在客户端实现(最终用户浏览器中的 JavaScript 等)，因为它需要特定的用户身份验证。

获取和设置的参数数量都很少(通常为 1 到 4)。像 REST(我更喜欢只获取)、XML-RPC 和 SOAP(可能有点过分，但具有显式定义的方法和返回的优点)这样的方法是通常的嫌疑对象。

根据您的观点/经验，哪种语言(从消费者的角度来看)最广泛“使用”且最容易实现的协议(protocol)可以满足这一需求？

Answer 1

对于 Java 和/或 .NET 之外的几乎所有消费者来说，SOAP 都是一场噩梦，除非情况发生变化，否则让 Java 客户端与 .NET 服务器对话(反之亦然)是一件痛苦的事情。如果您选择 SOAP 路线，那么您几乎会让自己和 Web 服务的使用者受制于工具支持，因为没有人愿意手动处理 SOAP。

您几乎可以用任何语言为 RESTful Web 服务编写消费者，因为它只需要一个 HTTP 库，尽管大多数主流语言都有库来帮助完成内容类型协商等工作。这些库顺便说一句，这对服务器来说也是一个巨大的胜利。

真正的 RESTful API 可以通过定义来发现:超文本作为应用程序状态引擎 (HATEOAS) 是 REST 的定义特征之一。公平地说，这在现实世界中通常被忽视，很大程度上是因为它太过分了。像 AtomPub 或 Sun 的云服务器管理 API 之一可能是真正 RESTful 服务的一个很好的例子。

无论您采用哪种方法，您都应该自己编写清晰的文档，而不是依赖自动生成的文档。这些在需要时是有用的引用，但它们不能取代良好的手写文档。