kintoneアプリをJavaScriptでカスタマイズしていると良く出くわすのが、この「400」や「520」のHTTPエラー。何度このエラーに遭遇したかは数え切れないですが、ミスの原因は偏っていて、原因がわかると「あぁ、またやっちまった、、、」と思うことが多々あります。
今回は、自分への戒めも込めて、ミスをしやすい部分を3つ挙げておきたいと思います。
そもそもHTTP 400/520 エラーって何なの?
Mozzilaのサイトでは、下記のように解説されています。
HyperText Transfer Protocol (HTTP) の 400 Bad Request レスポンスステータスコードは、何らかのクライアント側のエラーであると分かったために、サーバーがそのリクエストを処理しない (できない) ことを表します
kintoneの場合、520のエラーもバリデーションエラーが原因で表示されることがあります。要するに、400も520もリクエストの形式が誤っているということなんですね。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
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」などの指定が必要で、これがないと行の追加はできないのです。
1 2 3 4 |
var newRow = { value: { "NAME": {"type": 'SINGLE_LINE_TEXT', "value": "Jumpei Yamamoto"}, "AGE": {"type": 'NUMBER', "value": 30} }}; |
サブテーブルを編集・登録したい時は、フィールド形式が正しいことを確認するだけでなくフィールドタイプを指定することも忘れないよう気をつけましょう。
2. ルックアップは重複禁止の設定が必要!
ルックアップの場合は、フィールド形式自体はvalueを指定するだけで良いのですが、気を付けなければならないのは、登録、更新の際には関連付けるアプリのコピー元のフィールドを重複禁止にする必要があるということです。
JavaScriptでのカスタマイズを行わない場合は、コピー元のフィールドの重複禁止設定は必ずしも必要ではないので、その設定がされていないことが多いと思います。
しかしJavaScriptで登録・更新を行う際にはこの設定が必須となるので、関連付けるアプリの仕様を確認する必要があります。
そのデータが既に重複している場合は、全体のアプリの設計も見直さなければならず、結構厄介な問題になるので注意しましょう。
3. 添付ファイルのファイルキーは2種類あるから気をつけろ!
添付ファイルの登録・更新時のリクエストデータは下記のようになるのですが、ここで指定している「fileKey」というのが2種類あって、これが混乱を招く原因となっています。
1 2 3 4 5 6 7 8 9 10 |
"<フィールドコード>": { "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を使うのもこなれてくると、結構フィールド形式を確認せずにプログラムを書くようになって、このようなミスにはまることが増えてきます。
仕様に則って、プログラムを書いていきましょう。