API development practices

Throughout 2015, if you want to label yourself, it should be API.

Customize various API frameworks in different systems.

• When developing the API for the mall to connect with various e-commerce ERPs, I use an API interface compatible with SHOPEX, because all kinds of ERPs basically support it.
• When developing ZenTao’s API interface, I compared the support of the issue management system interface by mainstream IDEs on the market, and adopted Redmine’s API compatibility mode for development.
• Wait.

In the design of API, what I am most interested in should be compatibility. Although Oracle won the Java API lawsuit, API compatibility is undoubtedly a matter of benefit to others and oneself.

Needless to say the benefits!

Remember the advertising slogan: What’s in the world is in China; what’s in China is in the world!

Compatibility of analog interfaces: someone else’s interface is yours; your interface is someone else’s!

I don’t want to talk about the details of API design here, because if you design it yourself, you will often have different preferences and styles.

But once it is compatible, although the original proposer of the API will receive explicit or implicit benefits, it will undoubtedly be "good news" for the end users of the API. Of course, from the perspective of Linux community culture, this is unacceptable. The world should be colorful!

REST API design style is indeed concise, but most people have not realized the necessity of applying this style.

In any case, web programmers will inevitably shift from the original full-stack development thinking to API design thinking.

The above introduces API development practices, including aspects of content. I hope it will be helpful to friends who are interested in PHP tutorials.