kintone REST APIで400/520エラーが出た時に確認すべき3つのこと！

2022.9.26

Jumpei Yamamoto

kintoneアプリをJavaScriptでカスタマイズしていると良く出くわすのが、この「400」や「520」のHTTPエラー。何度このエラーに遭遇したかは数え切れないですが、ミスの原因は偏っていて、原因がわかると「あぁ、またやっちまった、、、」と思うことが多々あります。

今回は、自分への戒めも込めて、ミスをしやすい部分を3つ挙げておきたいと思います。

そもそもHTTP 400/520 エラーって何なの？

Mozzilaのサイトでは、下記のように解説されています。

HyperText Transfer Protocol (HTTP) の 400 Bad Request レスポンスステータスコードは、何らかのクライアント側のエラーであると分かったために、サーバーがそのリクエストを処理しない (できない) ことを表します

kintoneの場合、520のエラーもバリデーションエラーが原因で表示されることがあります。要するに、400も520もリクエストの形式が誤っているということなんですね。

var body = {
    "app": 1,
    "id": 1001,
    "record": {
        "文字列__1行": {
            "value": "ABC"
        }
    }
};

kintone.api(kintone.api.url('/k/v1/record', true), 'PUT', body, function(resp) {
    // success
    console.log(resp);
}, function(error) {
    // error
    console.log(error);
});

var body = {

"app": 1,

"id": 1001,

"record": {

"文字列__1行": {

"value": "ABC"

}

};

kintone.api(kintone.api.url('/k/v1/record', true), 'PUT', body, function(resp) {

// success

console.log(resp);

}, function(error) {

// error

console.log(error);

});

上記はkintone REST APIでのPUTのサンプルですが、これで言うところの「body」の中みが何かしら間違っている可能性が高い、ということがわかります。

まずは、基本のフィールド形式を確認してみましょう。フィールド形式の一覧はこちらのページに記載されていますが、中でも間違いやすいものを3つご紹介します。

1. サブテーブルの行追加はフィールドタイプの指定を忘れずに！

サブテーブルのフィールド形式はやたらと「value」が出てくるので、それだけでも複雑で混乱してくるのですが、よく説明書きを読んでみると、

テーブルに行を追加する場合、フィールドタイプの指定が必要です。

こんな記載があります。つまり、下記のように「SINGLE_LINE_TEXT」「NUMBER」などの指定が必要で、これがないと行の追加はできないのです。

var newRow = { value: {
    "NAME": {"type": 'SINGLE_LINE_TEXT', "value": "Jumpei Yamamoto"},
    "AGE": {"type": 'NUMBER', "value": 30}
}};

var newRow = { value: {

"NAME": {"type": 'SINGLE_LINE_TEXT', "value": "Jumpei Yamamoto"},

"AGE": {"type": 'NUMBER', "value": 30}

}};

サブテーブルを編集・登録したい時は、フィールド形式が正しいことを確認するだけでなくフィールドタイプを指定することも忘れないよう気をつけましょう。

2. ルックアップは重複禁止の設定が必要！

ルックアップの場合は、フィールド形式自体はvalueを指定するだけで良いのですが、気を付けなければならないのは、登録、更新の際には関連付けるアプリのコピー元のフィールドを重複禁止にする必要があるということです。

JavaScriptでのカスタマイズを行わない場合は、コピー元のフィールドの重複禁止設定は必ずしも必要ではないので、その設定がされていないことが多いと思います。

しかしJavaScriptで登録・更新を行う際にはこの設定が必須となるので、関連付けるアプリの仕様を確認する必要があります。

そのデータが既に重複している場合は、全体のアプリの設計も見直さなければならず、結構厄介な問題になるので注意しましょう。

3. 添付ファイルのファイルキーは2種類あるから気をつけろ！

添付ファイルの登録・更新時のリクエストデータは下記のようになるのですが、ここで指定している「fileKey」というのが2種類あって、これが混乱を招く原因となっています。

"&lt;フィールドコード&gt;": {
    "value": [
        {
            "fileKey":"84a0e9be-c687-4ae6-82be-3b7edab82c21",
        },
        {
            "fileKey": "722258d8-55e7-41ed-8208-adf3bd034e50",
        }
    ]
}

"<フィールドコード>": {

"value": [

{

"fileKey":"84a0e9be-c687-4ae6-82be-3b7edab82c21",

{

"fileKey": "722258d8-55e7-41ed-8208-adf3bd034e50",

}

]

}

実はこのfileKey、GETでレコード情報を取得した時に表示されるものと形式が異なるのです。よって、GETで得たfileKeyを、そのままリクエストデータに含めて登録しようとするとエラーが発生します。

GETの場合
- “fileKey”:”201202061155587E339F9067544F1A92C743460E3D12B3297″,
PUT/POSTの場合
- “fileKey”:”84a0e9be-c687-4ae6-82be-3b7edab82c21″,

こうして並べてみると、確かにfileKeyが異なることがわかりますよね。

PUT/POSTで指定しているfileKeyは、ファイルをサーバにアップロードした時に得られるデータになります。よって、kintone REST APIで、既にレコードに添付しているファイルを別のレコードを添付したい場合は、次の手順が必要になります。

添付されている該当ファイルを一度ダウンロードする
再度kintoneのサーバにアップロードする（fileKeyを取得する）
該当のレコードの添付ファイルフィールドにfileKeyをセットする

具体的な手順はこちらの記事に記載されている通りですが、添付ファイルフィールドを登録・更新しようとしてエラーが出る場合は、まずこちらのfileKeyが正しいかを確認してみましょう。

まとめ

kintone REST APIで400/520のエラーが出た時は、リクエストデータの形式に誤りがあることがわかりました。

エラー時には、特にミスしがちな次の3つを確認しましょう。

サブテーブルのフィールドタイプは指定しているか？
ルックアップのコピー元のフィールドは重複禁止の設定にしているか？
添付ファイルのfileKeyはPUT/POST用のキーを指定しているか？

kintone REST APIを使うのもこなれてくると、結構フィールド形式を確認せずにプログラムを書くようになって、このようなミスにはまることが増えてきます。

仕様に則って、プログラムを書いていきましょう。

無料相談はこちら