ForHosting KIT · 開発者向けツール

べき等性キーのフォーマットチェック

べき等性キーのフォーマットチェックは、Idempotency-Key ヘッダーとして送信する予定の文字列を受け取り、API に届く前に一般的なフォーマット指針に従っているかを判定します。キーが空でないこと、実用上ユニークになるだけの長さがあること、妥当な最大長を超えないこと、そしてすべての文字が URL セーフであることを検証し、ヘッダー・ログ・クエリ文字列の中でエンコードの問題なく生き残ることを確認します。文字列を1つ送ると、明確な valid フラグ、測定された長さ、問題がある場合はその具体的な一覧が返ってきます。

● Beta無料・ブラウザ内で実行
ご利用方法 ウェブAPIメールTelegramアプリ 近日

べき等性キーにフォーマットチェックが必要な理由

べき等性キーは、再試行されたリクエスト——二度送信された支払い、タイムアウト後に作成された注文——が一度だけ処理されるために存在します。しかし、その安全性はキー自体が正しい形式であることに依存します。短すぎるキーは他のクライアントのキーと衝突し、2つの異なる操作を静かに1つに重複排除してしまいます。URL セーフな文字集合に含まれない文字を含むキーは、クライアント、プロキシ、ログパイプライン、サーバーのどこかで壊され、再試行が元とは異なる文字列で到着して二重課金されます。空のキーは多くの API で即座に拒否され、しばしば原因追跡に半日かかる汎用エラーになります。このべき等性キーのフォーマットチェックをシステムの境界で実行すれば、3つの失敗モードすべてを開発時、テストスイート、あるいは自社サービス内の事前検証で捕捉でき、数週間後の照合レポートで発覚する事態を避けられます。

具体的に何が検証されるのか

このチェックは、決済事業者や重複排除ミドルウェアが最も頻繁に文書化しているフォーマット指針を適用します。第一に、キーは空でない文字列でなければなりません。空のキーは警告ではなくエラーです。どのサーバーも受け付けないからです。第二に長さです。デフォルトではキーは最低16文字——これを下回ると一意性が現実的でなくなる下限——で、最大255文字——ほとんどのストアが受け入れる上限——です。両方の境界は呼び出しごとに設定可能です。第三に文字集合です。すべての文字は RFC 3986 の非予約文字——英字、数字、ハイフン、ドット、アンダースコア、チルダ——から選ばれている必要があります。これらの文字は HTTP ヘッダー、URL セグメント、ログシッパーをエンコードなしで通過しますが、それこそべき等性キーが通る経路です。文字が失格した場合、レスポンスは問題のある文字を重複なく列挙するため、スペースやスラッシュ、絵文字が混入したかが分かり、issues 配列が問題を機械可読な形で示します:too_short、too_long、unsafe_characters です。

スタックのどこに組み込むか

多くのチームは2か所に組み込みます。1つ目はキーを生成するクライアントです。UUID、タイムスタンプ、ユーザー ID からキーを組み立てた直後に一度検証し、失敗したら警告を記録すれば、ジェネレーターのバグが本番ではなくステージングで表面化します。2つ目はコントラクトテストです。保有する各インテグレーションからのキーのバッチを CI でエンドポイントに送れば、エンコード動作を変えるライブラリのアップグレードがビルドを失敗させます。このエンドポイントは決定的かつステートレスで、何も保存されず、既出キーのリストも参照されず、同じ入力は常に同じ出力を生みます。つまり実際のキーで呼び出しても安全で、リクエストあたり $0.002 と安価なため、デプロイごとに実行できます。同じ検証はこのページのブラウザ上でも無料で動作するため、インシデント中に開発者が怪しいキーを貼り付けて、API と同じ答えを得られます。

決済リトライクライアントでキーを検証

Idempotency-Key ヘッダーを付ける前に生成キーを確認し、不正なジェネレーターが顧客の二重課金を起こす前に素早く失敗させます。

CI でインテグレーションをコントラクトテスト

各サービスが生成するキーをビルドごとにチェックに送り、ライブラリ変更がフォーマットを壊したらパイプラインを失敗させます。

重複排除インシデントのデバッグ

ログからのキーを無料のブラウザチェックに貼り付け、2回のリトライが別リクエスト扱いされた理由がエンコードか長さかを確認します。

料金はいくらですか?

リクエストあたり $0.002 です。同じチェックはこのページのブラウザ上で無料で実行できます。

キーは保存されますか?以前のキーと照合されますか?

いいえ。チェックはフォーマット——長さと文字——のみが対象です。何も保存されず、重複排除の状態も参照されません。

なぜ空のキーはチェック失敗ではなくエラーなのですか?

空のキーはフォーマットの選択肢ではなく、呼び出し側のバグだからです。問題がすぐ表面化するよう、API は無効な入力として拒否します。

どの文字が URL セーフと見なされますか?

RFC 3986 の非予約文字です:大文字・小文字の英字、数字、ハイフン、ドット、アンダースコア、チルダ。それ以外は invalid_chars に報告されます。

長さの上限・下限は変更できますか?

はい。min_length と max_length を渡してデフォルトの16と255を上書きできます。例えば64文字の上限を文書化しているプロバイダーに合わせられます。

valid の結果はキーが一意であることを保証しますか?

いいえ。チェックはフォーマットのみを検証します。一意性はキーの生成方法から生まれます。UUID などの高エントロピーなソースが一般的な答えです。

このページの機能はすべてAPIからも利用できます。自社システムに組み込みたいチーム向けのセクションです。それ以外の方は上のツールをそのままお使いください。

POSThttps://api.kit.forhosting.com/dev/idempotency-key-format-check

Bearerトークンで認証し、POST1回でタスクをキューに登録します。結果はWebhookまたは署名付きリンクで受け取れます。

curl -X POST https://api.kit.forhosting.com/dev/idempotency-key-format-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"key":"order-7f3a9c2e-2026-07-25"}'
{
  "key": "order-7f3a9c2e-2026-07-25"
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.idempotency_key_format_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

非同期APIです。task_idは即時に返ります。ポーリングは1秒あたり1リクエストまでです。

1リクエストあたり$0.002

単価はすべて公開しています。トークン換算や独自クレジットはありません。失敗したタスクは課金されません。

HTTPコード意味
401unauthorizedAPIキーが無効か、指定されていません。Authorizationヘッダーを確認してください。
402insufficient_balance残高が不足しています。チャージ後に再度お試しください。
404unknown_type指定されたタスクタイプは存在しません。タイプ名を確認してください。
429rate_limitedリクエストが多すぎます。しばらく待ってから再度お試しください。

KITの完全なドキュメントを見る →