Domain Name of API Service

The domain name of SCS for Redis API includes:

Region	EndPoint	Protocol
Beijing	redis.bj.baidubce.com	HTTP and HTTPS
Baoding	redis.bd.baidubce.com	HTTP and HTTPS
Guangzhou	redis.gz.baidubce.com	HTTP and HTTPS
Suzhou	redis.su.baidubce.com	HTTP and HTTPS
Wuhan	redis.fwh.baidubce.com	HTTP and HTTPS
Hong Kong	redis.hkg.baidubce.com	HTTP and HTTPS

Communication Protocol

API is called in accordance with HTTP protocol, each region should use a different domain name, and the specific domain name is “redis. {Region} .baidubce.com”. The data exchange format is JSON, and all “request/response body” contents is encoded in UTF-8.

Request Parameters

The request parameters include the following 4 types:

Parameter Type	Description
URI	Parameters used to indicate the operating entity, such as: POST/v (version)/instance/(instanceId)
Query parameters	Request parameters carried in the URL
HEADER	Parameters passed by HTTP header field, such as: x-bce-date
RequestBody	Request data body organized in JSON format

Return Value

The return values have two forms:

Return content	Description
HTTP STATUS CODE	Such as: 200, 400, 403, 404
ResponseBody	Response data body organized in JSON format

API Version Number

Parameters	Type	Parameter Position	Description	Required
version	string	URI Parameter	API version number (the current API version number is v1)	Yes

Authentication Mechanism

Access Key and request signature are used for all API security authentication. The Access Key consists of an Access Key ID and a Secret Access Key, and both of them are strings.

For each HTTP request, an authentication string is generated with the algorithm described below. Submit tge authentication string in Authorization header field. The server should verify the correctness of the authentication string based on the generation algorithm. The format of the authentication string is bce-auth-v{version}/{accessKeyId}/{timestamp}/{expirationPeriodInSeconds}/{signedHeaders}/{signature}.

• The version number is a positive integer.
• Timestamp is the UTC time when the signature is generated
• “ExpirationPeriodInSeconds” indicates the expiration date of the signature.
• “SignedHeaders” is the list of header fields involved in the signature algorithm The header domain names are separated by semicolons (;), such as host; X-bce-date. The list is in lexicographic order. (API signature only uses two headers of host and x-bce-date)
• The signature is a hexadecimal representation of a 256-bit signature, and consists of 64 lowercase letters.

Definition of Password Encryption Transmission Specification

All interface parameters involving password need to be encrypted and plaintext transmission is prohibited. All passwords is encrypted with AES 128-bit encryption algorithm, and with the first 16 bits of SK as the key. The binary byte stream generated after encryption is converted to the hexadecimal and transmitted to the server in the form of string. The specific steps are as follows:

• byte[] bCiphertext= AES(plaintext, SK)
• String strHex = HexStr(bCiphertext)

Idempotence

In case of a request timeout or an internal server error when calling the creation interface, the user may try to resend the request, creating more unexpected resources can be avoided with the clientToken parameter, so as to guarantee the idempotence of the request.

The idempotency is based on clientToken, which is an ASCII string with a length of up to 64 bits and is usually placed in a query string, such as http://redis.bj.baidubce.com/v1/instance?clientToken=be31b98c-5e41-4838-9830-9be700de5a20.

If a creation interface is called with the same clientToken value, the server will return the same request result. So, in case of an error, the creation interface can be re-called with the same clientToken value, to ensure that only one source can be created. If a used clientToken is provided, but other request parameters (including queryString and requestBody) are different and even url Path is different, IdempotentParameterMismatch error code will be returned.

ClientToken is valid in 24 hrs since that the clientToken was received by the server in the last time. That is to say, if the client sends the same eclientToken constantly, this clientTokem will be valid in a long time.

The users using the SCS for Redis API are required for the identity verification. The users who have not passed the identity verification can perform the identity verification under the security authentication in the Open Cloud official website console. The users who do not pass the identity verification will get the following error code:

Error Code	Error description	HTTP Status Code	Explanations
QualifyNotPass	The User has not pass qualify.	403	The account does not pass the identity verification