语言无关的API [英] Language Agnostic API

问题描述

我就准备把一个Web服务，或暴露在互联网上的一些其他服务。我想创建一个API，应用程序与该服务进行交互。我想在API是在不同的语言，例如Java，C ++，C＃，或PHP可用。我怎样才能维护一个code碱基对我的API，但对于分发所有这些语言很好的包装的二进制文件？另外，我可能要考虑这可能是跨平台以及。

I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.

更新1

我对Web服务的早期阶段，但我
  认为，关键点之一是，
  许多模具支持
  根据实施客户
  像WDSL服务的描述。
  我没有发表任何客户端
  与任何软件，我已经做了，我
  希望任何用户能够建立
  自己的客户适合自己
  需要。 --Brabster的答案

I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL. I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs. --Brabster's Answer

我不反对以使它然后直Web服务提供了一个WSDL文件。但是，如果我想在客户端API做一些逻辑，加密，错误检查或等什么？

I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?

更新2

至于期望在客户端是
  使用API​​做任何事情，你
  不能！没有什么，你会
  能够做到，以确保消费者
  该API会做任何事情的权利。
  这就是为什么健壮的错误处理是如此
  重要。您必须检查和双
  检查涉及任何和一切
  从客户端。你必须时刻
  可疑的是，甚至假设
  这是恶意的。真的是没有
  围绕这一事实很好的方式。 --Ryan纪廉的答案

As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact. --Ryan Guill's Answer

我最初的想法是建立在.NET DLL或组装，然后在客户端发出的呼叫到这个code运行的客户端。这code可通过任何通信协议顶嘴服务器，但我会API在他们的框中运行。我想REST并没有真正做到这一点。这似乎是在REST一切仍是一个HTTP POST。它与出肥皂几乎Web服务。

My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.

更新3

我已经接受了瑞安纪廉的回答。我觉得一般的想法是，我需要公开某种形式的网络服务，用最低的屏障给客户端。任何人都这样可以连接。然后，只需在服务器上的所有我的code运行。这似乎被接受作为唯一想要真正实现了平台和语言的独立性我了。

I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.

感谢所有的输入。

推荐答案

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

I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/

这是相当简单的创建和维护，最大的缺点是，它需要大量的文档（但pretty多，你做一个API都会有这个问题的任何方式），以及强大的错误处理是必须的。

It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.

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

But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.

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

更新：提交者添加了以下的帖子：

Update: The submitter added the following to the post:

我不反对以使它然后直Web服务提供了一个WSDL文件。但是，如果我想在客户端API做一些逻辑，加密，错误检查或等什么？

I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?

我个人不喜欢使用SOAP（使用WSDL）。有很多固有开销来使用SOAP，服务器和客户端上。我想这就是为什么你看到越来越多的公共API的使用REST被写入。这真的降低了进入壁垒最低公分母，允许任何可以使用基本的HTTP（GET和POST（也PUT和DELETE做吧）的正确的方式）来使用API​​。

I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.

公共API的使用REST写的一些例子：叽叽喳喳，的 VIMEO ，的谷歌

Some more examples of public API's written using REST: twitter, vimeo, Google

至于预期正在使用您的API做任何事情，你不能在客户端！你没有什么可以做，以确保API的消费者会做任何事情的权利。这就是为什么可靠的错误处理是非常重要的。你必须检查，并仔细检查来自客户端的任何和一切。你必须始终怀疑它，甚至认为这是恶意的。真的是围绕这一事实没有什么好办法。

As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.

更新2：提交者添加了以下的帖子：

Update 2: the submitter added the following to the post:

我最初的想法是建立在.NET DLL或组装，然后在客户端发出的呼叫到这个code运行的客户端。这code可通过任何通信协议顶嘴服务器，但我会API在他们的框中运行。我想REST并没有真正做到这一点。这似乎是在REST一切仍是一个HTTP POST。它与出肥皂几乎Web服务。

My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.

您当然可以这样做，但只会针对.NET语言的工作，也就是说你的跨平台和跨语言的好处是窗外。仍然，在最后，你真的preventing什么？开发商将要或者使用远程API，或当地的DLL或大会。无论哪种方式，他将不得不知道如何使用它，使用它的权利，否则，你要抛出一个错误。所有你真正做的是改变那里的错误也会从抛出。这可能是对你很重要（如果是这样，何况为什么），但实际上并没有改变公式中任何事情。

You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.

但你是在说，REST是一种像无SOAP的Web服务有些是正确的。技术上REST是Web的服务也一样，它只是网络服务纷纷前来通常是指SOAP。这真的是实现同样的事情用不同的方式。最大的区别是，虽然，它需要更多的节目，并在你的身边想（和客户端上可能更多的节目），但你交易，对于稳健性，在消费和服务器开销少，和尽可能多的观众的API 。这真的是最小公分母。

But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.

这篇关于语言无关的API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！