Is open API easy to use? For a small team...

Open APIs are a good thing:

From Google, Facebook, Twitter to various SNS and Weibo sites in China, most of them have an open API Based on HTTP + XML/JSON. With these open APIs, a simple mobile client can also do a lot of things. If they work with their own server programs, developers will soon be able to launch a low-cost client + network service. First of all, I would like to thank these API providers, but I also want to share my views:

I would like to recall that it is very lightweight and easy to use compared with the heavy HTTP APIs such as WebService and SOAP XML. I don't know if anyone remembers that when using JBuilder to automatically generate WebService code, I think only programmers who pay by the number of lines of code will miss those days.

However, the current open API still has a lot of room for improvement. I have at least encountered some problems:

The first problem: there is no difference between the third-party client and the server. For example, for authenticated login, oauth is used to prevent third-party sites from obtaining the user password and log on through the web interface before redirecting. This is suitable for third-party web servers. But for the client, I think this is an alternative. Webview is prone to loss of focus, interface loading latency, and it cannot prevent malicious clients from secretly obtaining accounts/passwords. What is the result? The best client directly performs special authentication without oauth. If an API is designed, a third party must bypass it to demonstrate its own technology, business negotiation, or user experience. The application scope of this API needs to be adjusted.

The second problem is that the API is often designed according to the logic integrity of the service, rather than the use case. A bad example is shown below, showing recent updates from friends, you need to first obtain the friend list ID, then obtain the personal information of each friend, and then obtain the text content produced by each friend. This is not a problem of calling three APIs. This is a problem of calling one + 2/* n APIs.

Third problem: client code is restricted when running background threads. Many APIs provide separate URLs for resources. If a large number of small pictures need to be displayed on the same screen, and the mobile phone has two different speeds: Mobile Phone and Wi-Fi, the client requires a large amount of code to handle asynchronous reading and error handling (please consider several website APIs to be supported at the same time ). this code is also very difficult to maintain. (this is a good method to write a page on the server and display it directly with webview on the client)

Last question: update! Updating an API on the server is a very fast task. However, the client is much slower, and it is common for different versions of the client to coexist. If the Open API is modified with incompatibility, the old client will be completely unavailable. If you use third-party API encapsulated libraries and it is not updated, you will be more painful. Our practice is to have a complete set of proxy API server on the server. The client tries its best to deal with its own API and puts the support for open APIs on the server, which can solve the problem. However, from the perspective of professional division of labor, not every client team should do this.

So what should we do?

If you are a client developer, isolation and encapsulation are necessary. If possible, try to put open APIs on the server for support to keep the client simple .(In addition, it is far from the unofficial API package!) If you are a server programmer, I really hope you can try client network programming, such as iPhone and Android. this helps you design better APIs. after all, you always need to use your own design.