百度智能云

All Product Document

          Reference

          General Description

          Authentication Mechanism

          The security authentication of all APIs utilizes the Access Key and request signature mechanism. Access Key consists of Access Key ID and Secret Access Key, both of which are strings. For each HTTP request, the algorithm described below is utilized to generate one authentication string. The authentication string is submitted in the Authorization header. The server verifies the correctness of authentication string based on the generating algorithm. The format of the authentication string is bce-auth-v{version}/{accessKeyId}/{timestamp}/{expirationPeriodInSeconds}/{signedHeaders}/{signature}.

          • The version stands for a positive integer.
          • The timestamp stands for the UTC time when the signature is generated.
          • The expirationPeriodInSeconds stands for the expiration period of signature. The signedHeaders stands for the header list involved in the signature algorithm. The headers are separated by a semicolon (;), e.g. host; x-bce-date. The list is arranged in lexicographic order. (This API signature only utilizes two headers of host and x-bce-date.)
          • The signature is the 256-bit signed sexadecimal notation, and composed of 64 lower-case letters.

          After Baidu Cloud receives a request of users, the system will use the same SK and authentication mechanism to generate an authentication string, and compare it with the authentication string contained in the user request. If the two authentication strings are the same, the system considers that the user has the designated operation privilege, and executes the related operations; if the two authentication strings are different, the system will ignore the operation and return an error code. For details of authentication mechanism, please see Authentication Mechanism.

          Communication Protocol

          Support HTTP and HTTPS call methods. HTTPS calling is recommended to improve data security.

          Description of Request Structure

          The data exchange format is JSON, and all request/response body contents are encoded in UTF-8.

          The request parameters include the 4 kinds below:

          Parameter Type Description
          URI It is used to indicate the operating entity, such as PUT /v1/user/{userName}
          Query parameter Request parameters carried in URL.
          HEADER Incoming through html header field, such as: x-bce-date
          RequestBody Request data body organized in JSON format.

          Description of Response Structure

          R response values are divided into two formats:

          Response content Description
          HTTP STATUS CODE E.g. 200,400,403,404, etc.
          ResponseBody Response data body organized in JSON format.

          Version Number

          Parameter Type Parameter position Description Required or not
          version String URI parameters API version number Required

          Date and Time

          There are various methods to express date and time. For the purpose of unification, unless there are conventions or corresponding specifications, all fields expressing date and time specified in the HTTP standard utilize GMT, and UTC time for other places expressing date and time. The users should follow ISO 8601, and the following restrictions are made:

          • Fields expressing the date all utilize the YYYY-MM-DD format, e.g.2014-06-01 which means June 1, 2014.
          • Fields expressing time all utilize the hh:mm:ss format, with the capital letter Z added at the end, which means UTC time. E.g. 23:00:10Z means UTC time: 23:0:10.
          • When the date and time is combined, the capital letter T is added between the two items, e.g. 2014-06-01T23:00:10z means UTC time: 23:00:10 on June 1, 2014.

          Normalized String

          Generally, one string can include any Unicode character. In programming, this kind of flexibility will bring about numerous troubles. Therefore, the concept of "normalized string" is introduced. One normalized string only includes the percent-encoding characters and URI (Uniform Resource Identifier) unreserved characters. RFC 3986 stipulates that "URI non-reserved characters" include the following characters: Letters (A-Z, a-z), numbers (0-9), hyphen (-), dot mark (.), underline (_), tilde (~). The method to change any string into a normalized string is:

          • To convert strings into UTF-8 encoded byte stream.
          • To keep all "URI non-reserved characters" unchanged.
          • To make the Percent-encoding specified in RFC 3986 once for the rest bytes, namely, two sexadecimal strings representing the byte value are behind one "%". All the letters are in upper case.

          Example: Original string: This is an example for test, Corresponding specification string: this%20is%20an%20example%20for%20%E6%B5%8B%E8%AF%95

          Previous
          Brief Introduction
          Next
          Enterprise Organization Management Interface