WeChat Service Code Development notes

The principle service number principle is relatively simple. From the perspective of request response, the logic is: User client-server-service number backend Program-database or WebService, that is, the server on which users' requests first pass, the server forwards the request to the Service Number Background Program. Since it is a server

The principle service number principle is relatively simple. From the perspective of request response, the logic is: the user client-server-Service Number Background Program-database or Web Service, that is, the server on which the user's various requests first pass, the server forwards the request to the Service Number Background Program. Since it is a server

Principle

The principle of service number is relatively simple. From the perspective of request response, the logic is:

User client <---> server <---> Service Number Background Program <---> database or Web Service

That is, the server that passes the user's various requests first forwards the requests to the Service Number Background Program.

Since the server forwards the user request data to the developed Service Number Background Program, a URL is required when the service number development mode is enabled. In addition, a token is required to verify whether the request comes from the server. For the verification method, see the developer documentation. There are two types of verification:

When a developer submits a Verification Application for the first time, the server sends a GET request to the URL filled in with four parameters (signature, timestamp, nonce, echostr ), the developer verifies the signature to determine the authenticity of the message.

After that, each time a developer receives a user message, the previous three parameters (signature, timestamp, and nonce) will be included to access the URL set by the developer, the developer still checks the authenticity of the message by verifying the signature. The verification method is the same as the verification application submitted for the first time.

The messages forwarded by the server to the Service Number Background Program and the responses returned by the Service Number Background Program to the server are in XML format. Both the sender and receiver are indicated in the message. The sender in the request message is the user's openid, the receiver is the service number developer number, and the response message is the opposite.

There is also a keyword field MsgType in the message to specify the message type. Request messages are divided into three categories: common messages, event push, and speech recognition results,

• There are six types of common messages: text, images, voice, video, geographic location, and link.
• Event push is divided into four types: follow/cancel follow events, scan QR code events with parameters, report geographical location events, and customize menu events (push events when you click a menu to pull a message, and push events when you click a menu to jump to a link)

There are also 6 types of response messages: text, images, voice, video, music, and text.

The service number developed for the product at work. Currently, for common messages, the service number background program automatically responds to a text message. For the follow events in event push, it is a text message that responds to a welcome and feature introduction.

In addition, we use a custom menu event. To use this event, you must first provide a custom menu for your service number. Custom menus are pushed to them through provided APIs.

When pushing a custom menu to the server through an API, the server needs to confirm whether a request is trusted. The confirmation method is based on the request parameter access_token. Access_token needs to be obtained from the server through API. After the development mode of the service number is enabled, an AppId and AppSecret will be assigned to the service number. When obtaining the access_token, these two parameters are required for the server to confirm whether the service number has been registered. For more information about access_token, see here.

After obtaining the access_token, you can create, delete, and query the custom menu of the service number through the API.

For more information about the custom menu, see here.

The following Python code is a simple encapsulation of custom menu APIs:

Development

For the service number background program, you can refer to the official documentation to start from scratch. However, many sdks are available for unofficial public accounts. For example, this is the phpsdk I use.

You can also find sdks in other languages.

Note:

• After I enable the Service number development mode, I directly use this service number for development and testing. However, some product users have followed this service number during the development and testing process, in this process, the user experience will be poor. The correct process should beApply for a test account for development and testing, and then launch the service number after the development and testing is complete..

• After a custom menu is changed, it is not updated in real time. The official documents describe:After the custom menu is created, it takes 24 hours for the client to appear because of the client cache. We recommend that you try to remove the public account and follow it again during the test to see the effect after creation..

• The client should be based on the browser kernel technology, so it can explain the rendering of web page elements. The image in text message is actually an img element, so you need to provide your own graph bed. The message sending function provided by the official public platform must contain images for text and text messages, but the image link can be left blank in the text message returned by the Service Number Background Program, in this way, you may need to receive text messages. In addition, text messages can also contain hyperlink.

Original article address: service number Development notes. Thank you for sharing them.