问题 语言不可知API [已关闭]

我会使用REST API，类似于Flickr的API工作方式： http://flickr.com/services/api/

创建和维护起来相当简单，最大的缺点是它需要大量文档（但几乎任何方式你都会遇到这个问题）并且必须具备强大的错误处理能力。

但在我看来，这是创建最接近跨平台/跨语言的API的最佳方式。

更多信息： http://www.xfront.com/REST-Web-Services.html

更新：提交者在帖子中添加了以下内容：

我不反对将它作为一个直接的Web服务，然后发出一个WSDL文件。但是，如果我希望客户端API执行某些逻辑，加密，错误检查等，该怎么办？

我个人不喜欢使用SOAP（使用WSDL）。在服务器和客户端上使用SOAP有很多固有的开销。我认为这就是为什么你看到越来越多的公共API使用REST编写的原因。它确实降低了进入最低公分母的障碍，允许任何可以使用基本HTTP（GET和POST（以及“正确”方式的PUT和DELETE））来使用API​​。

使用REST编写的公共API的更多示例： 推特， VIMEO， 谷歌

至于期望使用您的API的客户做任何事情，您不能！您无法做任何事情来确保API的使用者能够做任何事情。这就是强大的错误处理如此重要的原因。您必须检查并仔细检查来自客户端的任何内容和所有内容。你必须始终怀疑它，甚至认为它是恶意的。这个事实真的没有好办法。

更新2： 提交者在帖子中添加了以下内容：

我最初的想法是在.NET中创建一个DLL或程序集，然后客户端调用这个运行客户端的代码。此代码可以通过任何通信协议与服务器通信，但我的API将在其盒子上运行。我想REST并没有真正做到这一点。好像在REST中，一切仍然是HTTP帖子。这几乎是肥皂的网络服务。

您当然可以这样做，但这只适用于.NET语言，这意味着您的跨平台和跨语言优势已经不再适用。最后，你真的在​​阻止什么吗？开发人员将使用您的远程API或本地DLL或程序集。无论哪种方式，他将不得不知道如何使用它并正确使用它，否则你将抛出错误。你所做的一切只是改变错误的发生地。这对您来说可能很重要（如果是这样，请提及原因），但实际上并没有改变方程式中的任何内容。

但是，你说REST有点像没有SOAP的Web服务，这有点正确。从技术上讲，REST也是Web服务，它只是Web服务通常意味着SOAP。这实际上是实现同样事情的另一种方式。最大的不同之处在于它需要更多的编程和思考（并且可能在客户端进行更多的编程），但是您需要交换它以获得稳健性，减少消费者和服务器的开销，以及最广泛的API受众。它确实是最低的共同点。