Recently, in order to prepare for the development of private cloud, we have studied the access of Heroku third-party services. Here we will summarize the highlights of Heroku in this aspect.
1. Powerful access tools need to integrate their own services into Heroku. You need to set a protocol with Heroku, develop it according to the protocol, verify it, and finally release it to Heroku. This process takes a long time, while Heroku provides a command line tool named kensa, which can reduce a lot of work, especially the test functions. It is quite convenient to gradually verify the access conventions, looking back at your previous project, you need to perform Machine Access. Many of them are manually verified, which is quite primitive and lagging behind. However, if the graphic interface is provided, I think it will be more advanced.
2. The detailed access documentation is needless to say. I cannot write these articles without these documents.
Iii. Mandatory agreements, rather than the vendor-defined interface protocols, third-party vendors can only customize service addresses, and most others must follow Heroku's conventions. Heroku is set first. A third-party vendor must provide a dedicated Heroku interface-your-add-ons/Heroku/resources. The interface name must end with Heroku/resources, and then the parameter of this interface, request method. The returned results must follow the requirements of Heroku. This reduces the cost of joint debugging by both parties (in fact, joint debugging is not required. For Heroku, if there are hundreds of third-party services, it must be in a forced way. Previously, when my project was connected to other services, other services were allowed to be defined by myself, mainly because there were not many access services in my project and there was human resources to adapt. However, if you want to support more services, you should adopt the agreed approach like Heroku.
4. the hierarchical publishing system defines the concepts of Beta, gray version, and official version. Third-party services must fulfill the requirements of these versions step by step before they can be officially released. This improves the overall quality of services and reduces the damage to users of poor plug-ins.
5. The protocol is stored as a local file by a third-party vendor and Heroku. The template is defined by Heroku. A third-party vendor must enter the service address, resource variable, and other information. Heroku can also allow the vendor to fill in the information on the website, but Heroku does not do this, but is stored in the third-party vendor's own code in the form of a configuration file (of course, at the end of the release, we still need to push this file to Heroku.) I am considering the benefits of Heroku. The biggest benefit of doing so is the convenience of testing. Without this configuration file, many kensa test functions cannot be performed.
Heroku is a reference for third-party service access.
