Change to Default API Version 1.1 and Compatibility with Previous Versions
Overview¶
In version 1.3.13.0, the default API version will change from 1.0 to 1.1, altering the data layout of API requests and responses. In addition, a bug in versions before 1.3.12.0, where the ApiVersion was not correctly set in requests without an API key, has been resolved, resulting in similar changes. Parameter adjustments are required to maintain compatibility with API calls developed in the older version.
Changes in API Version 1.0/1.1¶
The data layout of API requests and responses will change as follows:
API Version 1.0¶
The data layout of the following columns is expressed in a flat structure.
Responses for the above columns are, for example, from ClassA to Class100 for the class column. If you need responses for Class101 and beyond, please use API version 1.1.
API Version 1.1¶
The data layout of the following columns will be changed to KeyValue format.
How to Specify API Version¶
The default API version is set by the Version parameter in Api.json. It can also be explicitly specified by the API request parameters.
Specifying by the Version Parameter in Api.json¶
This version is used for API calls that do not specify the API version. The default value is 1.1. To use the specifications of the older version, change it to 1.0.
Specifying by Request Parameters¶
The API version can be specified by the ApiVersion request parameter when executing the API. If the request parameter is not specified, the value of the Version parameter in Api.json is used. To use the specifications of the older version, specify 1.0.
Request for the Record Retrieval API¶
Request for $p.apiGet¶
Compatibility_1_3_12 Parameter in Api.json¶
Compatibility_1_3_12 is a parameter for maintaining compatibility when API calls affected by a bug1 that existed in versions before 1.3.12.0 are present. The default value is false.
- If you are using the applicable API calls, change the
Compatibility_1_3_12parameter totrueand change theVersionparameter in Api.json to 1.0. - This bug did not occur in the .NET Framework version. When migrating from the .NET Framework version, set the
Compatibility_1_3_12parameter tofalse.
Applicable API Calls¶
In versions before 1.3.12.0, there was a bug where, in cases where ApiVersion is specified but ApiKey is not specified, the "ApiVersion": 1.1 specification was ignored and it operated with version 1.0.
In version 1.3.13.0 and later, this bug is fixed, so the behavior changes to that of API version 1.1.
Behavior of "Compatibility_1_3_12": false¶
The bug is fixed, and it operates with the specified API version.
| ApiVersion | ApiKey | Behavior |
|---|---|---|
| Not specified | Version in Api.json | |
| 1.0 | Specified | 1.0 |
| 1.0 | Not specified | 1.0 |
| 1.1 | Specified | 1.1 |
| 1.1 | Not specified | 1.1 |
Behavior of "Compatibility_1_3_12": true¶
As in versions before 1.3.12.0, the specification of ApiVersion is ignored.
| ApiVersion | ApiKey | Behavior |
|---|---|---|
| Not specified | Version in Api.json | |
| 1.0 | Specified | 1.0 |
| 1.0 | Not specified | 1.0 |
| 1.1 | Specified | 1.1 |
| 1.1 | Not specified | Version in Api.json |
Related Information¶
- Manage Table: Items: Class
- Manage Table: Items: Numeric Value
- Manage Table: Items: Date
- Manage Table: Items: Description
- Manage Table: Items: Check
- Manage Table: Items: Attachments
- Api.json
- Developer's Guide: API: Table Operation: Retrieve Multiple Records
- Developer's Guide: Script: $p.apiGet
-
The problem where ApiVersion was not correctly set in requests that do not specify an API key. ↩