选择 Web 服务的方法
我被要求建立一个新的网络服务，该服务应该可以在任何可能的语言（php、.NET、Java 等）中轻松使用。当然，可以自己滚动，接受不同的内容类型（xml / x-www-form-urlencoded（普通帖子）/json / 等），但现有的方法或机制当然是首选，可以减少时间花费在服务消费者的开发上。
Web 服务确实接受修改/设置（这不仅仅是简单的数据检索），但这些修改/设置很可能会比获取的少很多（我们估计大约 2.5% 的设置，97.5 次获取）。这里的术语 webservice 表示协议应该通过 HTTP，不能完全在客户端实现（最终用户浏览器中的 JavaScript 等），因为它需要特定的用户身份验证。
get 和 set 的参数数量都很少（通常为 1 到 4）。像 REST（我更喜欢只获取）、XML-RPC 等方法SOAP（可能有点矫枉过正，但具有显式定义方法和返回的优点）是通常的嫌疑人。
根据您的观点/经验，不同语言中最广泛“口头”且最容易实现的协议（从消费者的角度来看）可以满足这一需求？
I'm asked to set up a new webservice which should be easily usable in whatever language (php, .NET, Java, etc.) possible. Of course rolling my own can be done, accepting different content-types (xml / x-www-form-urlencoded (normal post) / json / etc.), but an existing method or mechanism would of course be prefered, cutting down time spent on development for the consumers of the service.
The webservice does accept modifications / sets (it is not only simply data retrieval), but those will most likely be quite a lot less then gets (we estimate about 2.5% sets, 97.5 gets). The term webservice here indicates the protocol should go over HTTP, not being able to implement it totally client sided (javascript in the end-users browser etc.), as it needs specific user authentication.
Both gets and sets are pretty light on the parameter count (usually 1 to 4). Methods like REST (which I'd prefer for only gets), XML-RPC & SOAP (might be a bit overkill, but has the advantage of explicitly defined methods and returns) are the usual suspects.
What in your opinion / experience is the most widely 'spoken' and most easily implementable protocol in different languages (seen from the consumers' viewpoint) which could fullfill this need?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
对于除了 Java 和/或 .NET 之外的几乎所有消费者来说，SOAP 都是一场噩梦，除非事情发生了变化，否则让 Java 客户端与 .NET 服务器对话（反之亦然）是一件痛苦的事情。如果您选择 SOAP 路线，那么您几乎会让自己和 Web 服务的使用者依赖于工具支持，因为没有人愿意手动处理 SOAP。
您可以用几乎任何语言为 RESTful Web 服务编写消费者，因为它所需要的只是一个 HTTP 库，尽管大多数主流语言都有库来帮助完成内容类型协商等事情。这些库是一个很大的库。顺便说一句，服务器也赢了。
真正的 RESTful API 可以通过定义来发现：超文本作为应用程序状态引擎 (HATEOAS) 是 REST 的定义特征之一。公平地说，这在现实世界中通常被忽视，很大程度上是因为它太过分了。像 AtomPub 或 Sun 的云服务器管理 API 之一可能是真正 RESTful 服务的一个很好的例子。
无论您采用哪种方法，您都应该自己编写清晰的文档，而不是依赖自动生成的文档。这些在需要时是有用的参考，但它们不能取代良好的手写文档。
SOAP is a nightmare for almost any consumer except Java and/or .NET, and unless things have changed, getting a Java client to talk to a .NET server (or vice versa) is a pain. If you go the SOAP route, you pretty much consign yourself and the consumers of your web service to being beholden to tool support, because nobody wants to deal with SOAP by hand.
You can write a consumer for a RESTful web service in pretty much any language, because all it needs is an HTTP library, although there are libraries for most mainstream languages to help with things like content-type negotiation, etc. Those libraries are a big win for the server, too, btw.
A truly RESTful API is discoverable by definition: Hypertext As The Engine Of Application State (HATEOAS) is one of the defining characteristics of REST. To be fair, this is typically ignored in the real world, largely because it's overkill. Something like AtomPub or one of the cloud server management APIs from Sun is probably a good example of a truly RESTful service.
No matter which approach you take, you should be writing clear documentation on your own instead of relying on auto-generated docs. Those are useful references when needed, but they don't take the place of good, hand-written documentation.
我们对此做了很多研究，最终选择了 REST。许多经过深思熟虑的 Web 服务都使用 REST，包括 Amazon S3。我认为 Gmail 在后端也使用了 REST。
根据我的观察，RESTful Web 服务设计似乎变得更加突出，因为随着时间和经验的推移，其设计的优点和其他设计（例如 SOAP）的缺点变得更加明显。
REST 似乎运行良好的原因是，它非常适合 Web 的客户端-服务器性质，将安全和幂等的 GET 请求、幂等的 PUT 请求以及既不安全也不幂等的请求的 POST 分开。它已经存在很长时间了，因此正确布局的 RESTful Web 服务可以被各种 Web 客户端使用，其中一些客户端甚至是您可能没有预料到的。例如，网络爬虫只知道使用 GET 请求资源，因为它保证不会影响资源，而 PUT 和 POST 请求具有不同的规则。
在我们决定采用 RESTful 服务架构之后，我读了这本书：RESTful Web Services 为了学习基础知识。如果你决定读这本书，要知道这本书的长度可能是所需长度的两倍，所以你必须明智地决定读什么和跳过什么——因为你会想跳过那些废话。
We did a lot of research on this and ended up going with REST. A lot of well-thought-of web services use REST including Amazon S3. I think Gmail also uses REST on the back end.
From my observation, RESTful web service design seems to be becoming more prominent as the advantages of its design and disadvantages of other designs such as SOAP become more obvious through time and experience.
The reason that REST seems to work well is that it is a natural fit for the client-server nature of the web with its separation of safe and idempotent GET requests, idempotent PUT requests, and POST for requests that are neither safe nor idempotent. Its been around for a long time so a properly laid-out RESTful web service can be consumed by a variety of web clients, some that you might not even anticipate. An example of this is that a web crawler will know only to request resources using GET because it is guaranteed not to affect the resource whereas PUT and POST requests have different rules.
After we decided on a RESTful service architecture, I read this book: RESTful Web Services in order to learn the basics. If you decide to read it, know that the book is perhaps twice as long as it needs to be so you'll have to be judicious about what to read and what to skip - cause you'll want to skip the fluff.
SOAP 服务具有可发现的优点。在 .NET（我假设还有其他语言）中，您只需创建一个新的 Web 服务类（ASP.NET 中的 .ASMX）并将任何方法添加到您需要的接口中。该框架将为您生成一个可通过 HTTP 检索的 WSDL。该 WSDL 包含一个类定义，调用应用程序使用该类定义为每个方法提供正确的参数名称和类型。 REST 或其他通常不可发现的服务的缺点是
您必须手动维护该接口的文档。如果没有 WSDL 中的信息和执行，调试与客户端的通信问题可能会更加困难。
A SOAP service has the advantage of being discoverable. In .NET (and, I assume, other languages), you simple create a new web service class (.ASMX in ASP.NET) and add whatever methods to the interface that you require. The framework will generate a WSDL for you that is retrievable via HTTP. That WSDL contains a class definition that is used by the calling application supply correct parameter names and types for each method. etc.
A REST or other typically non-discoverable service has the disadvantage that you'll have to maintain documentation for that interface manually. It can be more difficult to debug communication issues with clients without the information within and enforcement of a WSDL.