Live/im/api/en
(→Post Comments) |
(→Receive Comments-Pull Mode) |
||
第95行: | 第95行: | ||
|- | |- | ||
!width="15%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Parameter field | !width="15%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Parameter field | ||
− | !width="10%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"| | + | !width="10%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Requires |
!width="10%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Field Type | !width="10%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Field Type | ||
!width="65%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Field description | !width="65%" style="text-align:left;padding-left:5px;font-weight:bolder;border:1px solid #cccccc"|Field description |
2017年2月24日 (五) 16:47的版本
目录 |
Overview
One of the cooperation mode between weibo and the third-party that access to weibo is server-side synchronization.This mode means doing message synchronization between live interactive system of weibo and interactive system of the third-party to implement message sharing. Send message interface and pull message interface(active pull and callback pull)can synchronize third-party messages to weibo.
Post Comments
Description
Post comment of the users to weibo live-im system.
URL
https://api.weibo.com/2/liveim/message/sync.json [POST]
Support Formats
JSON
Authorization
Required. More details of login authorization, Please refer to this WIKIHow to login to authorization
Request parameter
Parameter field | Requires | Field Type | Field description |
---|---|---|---|
access_token | true | string | Required parameters when using OAuth authorization mode,obtained after OAuth authorization |
room_id | true | string | room id |
ts | true | long | Timestamp(The number of milliseconds from 1970-01-01 00:00:00),cannot delay more than 2min |
msg_type | true | int | message types, see message types |
content | true | string | Message content |
uid | true | long | sender ID |
nickname | true | string | Sender nickname |
avatar | true | string | sender avatar url |
sign | true | string | The result of signing all the parameters other than sign ,See signature algorithm |
extension | false | string | message extension field see (json object format, the default is empty json object) |
offset | false | long | the time offset between sending message and the start of the live,unit:ms.If not pass, or pass the negative, do 0 process,indicating that the current message is not displayed when playing back. |
Return result
//Successful return
{ "error_code":0, //0 indicates success,while others mean failed. Need to see the error message "error_msg":"" }
//Failed to return
{ "error_code": 91XX, "error_msg": "xxxxxxxxx" }
Receive Comments-Pull Mode
Description
This interface allows the third-party pull room messages from weibo live interactive system.After the third-party initiates the request,the interface will push the latest message in the room continuously as long as the connection is not broken.If the connection is disconnected accidentally,the message will continue to be pushed from the last disconnected position as long as the cumulative number of messages before the reconnection does not exceed the agreed threshold.
URL
https://api.weibo.com/2/liveim/message/pull.stream [GET]
Support Formats
JSON
Authorization
Required. More details of login authorization, Please refer to this WIKI How to log in to authorization
Request parameter
Parameter field | Requires | Field Type | Field description |
---|---|---|---|
access_token | true | string | Required parameters when using OAuth authorization mode,obtained after OAuth authorization |
room_id | true | string | room id |
Return Result
The return message is pushed in JSON mode, and the data structure is pushed as follows. Each message is a separate JSON-OBJECT.
//Successful return
{ "error_code":0, //0 indicates success,while others mean failed. Need to see the error message "error_msg":"", } { // message body. See Annex [Data structure / message body] } { // message body. } ...
//Failed to return
{ "error_code": 91XX, "error_msg": "xxxxxxxxx" }
about error return values and error codes, seeError Code Definitions
Receive Comments-Callback Mode
Description
If the third-party uses HTTP Callback mode to accept weibo messages,the third-party needs to provide an interface similar to [send message interface]. Requires the same parameters and return values as that interface.
URL
customize by the third-party
Support format
JSON
HTTP request mode
POST
Authorization
Required. More details of login authorization, Please refer to this WIKIHow to log in to authorization
Request parameter
Parameter field | Field must be selected | Field Type | Field description |
---|---|---|---|
source | true | string | AppKey applied when applying for application,When calling an interface, it represents the unique identity of the application(This parameter is not required when using OAuth authorization mode) |
room_id | true | string | room id |
ts | true | long | Timestamp(The number of milliseconds from 1970-01-01 00:00:00) |
msg_type | true | int | Message Type 1 - Comment Message 2 - Praise message |
content | true | string | Message content |
uid | true | long | sender ID |
nickname | true | string | sender nickname |
avatar | true | string | sender avatar url |
sign | true | string | The result of signing all the parameters other than sign ,Seesignature algorithm |
extension | false | string | message extension fieldsee(json object format, the default is empty json object) |
offset | false | long | the time offset between sending message and the start of the live,unit:ms.If not pass, or pass the negative, do 0 process,indicating that the current message is not displayed when playing back. |
Return result
//Successful return
{ "error_code":0, //0 indicates success,while others mean failed. Need to see the error message "error_msg":"" }
//Failed to return
{ "error_code": 91XX, "error_msg": "xxxxxxxxx" }
Signature Algorithm
Input:
- the list of key-value pairs
- appsecret used to signature
Output:
Signature Result String
Algorithm:
- Each of the key-value pair composes a string follows key=value format,each string is sorted by the dictionary order of the key(key is not the same),then a semiangle sign "&" is used to form a string.
- The string is encoded in UTF-8 to get a byte sequence input,the secret string is encoded by UTF-8 to generate a byte sequence as the key,the byte sequence of the hash value is calculated in the form of hmac-md5,the hash-value byte sequence uses URL-safe-Base64 encoding,then take the 6th to 16th characters as the result output.
Algorithm Example:
Assume that the input is: kv-pair: {"a":"1", "c":"jerry", "b":"tom"} appsecret: 123456
the concatenated string is: a=1&b=tom&c=jerry
hmac-md5("a=1&b=tom&c=jerry",123456) byte array output:[-117, -27, -78, -5, 73, 68, -64, -50, 4, 21, 16, -55, -55, -39, -31, -15]
converted to URL-safe base64 string:i-Wy-0lEwM4EFRDJydnh8Q== take the 6th to 16th characters(initial bit is 0), contains the 6th, does not contain the 16th, a total of 10 bits:lEwM4EFRDJ
Signature results:
lEwM4EFRDJ
Data Structure
Message Body
{ "room_id":string, // room id "room_sys_id": uint64, // room id (internal) "msg_type":int, // Message type, see "Message Type Description" "mid":long, "sender_info":{ // user information of the sender, see "User Information" }, "content":string, // message content "extension":string, // The extended field of the message "offset": long, // the offset of message time from the video start time,unit:ms "created_at":long // Timestamp,the number of milliseconds from 1970-01-01 0:00:00 GMT //If there are other fields, these fields continue here,related fields See "Additional fields for each message type" }
extension
For the message types 1 to 14, each kind of message will have some unique fields used to represent the business, these fields will appear in the sys field inside of the extension, the structure is as follows:
extension = { "sys": { // The fields that appear here are listed in "unique additional fields to each type".If the extra field list is empty, the "sys" field may not exist }, // "Other transparent fields" }
unique additional fields to each type
chat message,msg_type=1 "msg_behavior":uint32 //the display behavior of message 0: Default 1. Barrage praise message,msg_type=2 "praises_count":int // Current total number of praise "inc_praises":long // the number of times that users point like banned,msg_type=4 "shut_info":{ // the users be banned "shutted_until":uint32 //the remaining time of the end of prohibition,unit:s "members":[ //User list that be banned { "uid":uint64 //the UID of the user that be banned "user_system":string //the system that the banned user belongs to } ] } room change,msg_type=11 "live_status":int // Indicates the status of the live broadcast "room_info": { // Room information body, see "room information" } join room and exit room,msg_type=12 "exit_or_enter_room":int // 0:exit 1:join "room_info": { // Room information body, see "room information" } add and delete administrator,msg_type=14 "admin_info":{ // information of users that be added or deleted "uid":uint64 //UID of the administrator "user_system":string //the system that the administrator belongs to "type":int //Operation Type 1:Add 2:Delete }
Live Interface
Please refer tolive interface documentation
Message Type
1 - chat message 2 - praise message 3 - light the anchor message 4 - banned message 6 - announcement message 7 - share live messages 8 - focus on the anchor message 11 -live change message (any change in room status will be pushed) 12 - join / exit room message 13 - reward message 14 - administrator change message 100 - customize message type
Error code definition
error code | error description |
---|---|
9101 | authentication failed |
9102 | internal error |
9103 | data format error |
9104 | the message contains spam |
9105 | already exists |
9106 | data is not legal.the point that unlike 9103 : 9103 is the data format error, such as a int parameter should be passed but passed a string can not be resolved into int. And the current error code indicates that the data format itself is not a problem, but is an illegal data, such as ID corresponding entity does not exist. |
9107 | room is not allowed to speak |
9108 | user does not exist |
9109 | room does not exist |
9110 | token parse error |
9111 | room status is not correct |
9112 | the user is banned |
9113 | the current operation is not allowed |
1019 | the current operation is not supported |