curlコマンドでの設定追加のリスクについて

完了
フォローする
michelle
  • 編集済み

お世話になっております。
標記の件について、確認よろしくお願いします。

【前提】
　・AlertHub及びPigeonの既存稼働環境にKompiraAPIのコマンドをcurlで実行して
　　既存環境とは別の定義を新たに登録することを検討しています。

【確認事項】
　・KompiraAPIのコマンドをcurlで実行する際のリスクは何かあるでしょうか？
　　※CSVインポート機能は使用しない予定です。

　　　→curlでKompiraAPIのコマンドを実行して、仮にエラーが発生しても既存稼働環境に
　　　　影響しない想定です。
　　　　齟齬はないでしょうか？
　　　　※既存稼働環境が壊れることを一番気にしています。

　　　→仮にJSONをもとに登録コマンドを実施してエラーが発生しても、適宜JSONを変更して
　　　　ステータスコード201が帰ってくるまで、コマンド再実行すればいい想定です。
　　　　登録した定義内容に問題がある場合も然りの想定です。
　　　　齟齬はないでしょうか？

以上、よろしくお願い致します。

0

コメント

4件のコメント

日付 投票
  • 正式なコメント
    Kompiraサポートチーム

    お問い合わせありがとうございます。
    ご質問の件、以下回答させていただきます。

    KompiraAPIのコマンドをcurlで実行する際のリスクって何かあるのでしょうか？

    API 実行を行うクライアント (curl など) による動作の切り替えは行っていないため、同じ API 呼び出しを行う限り、API 呼び出しを行うコマンドによって動作が変わるということはありません。

    →curlでKompiraAPIのコマンドを実行して、仮にエラーが発生しても既存稼働環境に影響しない想定です。

    この認識については、画面操作では避けられている操作がこちらできてしまうことで、データ整合性に矛盾が生じるなどの悪影響がないかといった意図でのご質問でしょうか。
    もしそうであれば、データ破損などの心配はございません (※)。
    例えば、必須項目が未指定、表示名が長すぎる、存在しない受信スロットを指定してルールを作成する、ルールによって参照されている受信スロットを削除仕様とするなどといった、成功してしまうと不整合が発生してしまう操作については操作が棄却されて 4xx 系エラーが返り、矛盾が発生しないようになっています。
     
    ※ただし、現状、以下については整合性が取れない結果となる操作が可能となっていますのでご注意ください。ちなみに画面からの操作でも同様です。
    • ランブックのアクションステップからしか参照されていないアクションを削除する
    • ランブックのイベントステップからしか参照されていないスコープを削除する

    →仮にJSONをもとに登録コマンドを実施してエラーが発生しても、適宜JSONを変更してステータスコード201が帰ってくるまで、コマンド再実行すればいい想定です。登録した定義内容に問題がある場合も然りの想定です。

    こちらは、誤った内容を作成しようとしてエラーが返ってきた後で、少しずつ修正して正しいデータを登録していこうとお考えでしょうか。
    もし、そのような使い方であってもデータ整合性が壊れることはありませんので問題ございません。
    ただし、同じ URL の API 呼び出しを短時間に大量に試行されると API 呼び出し数制限に抵触し、 429 エラーが返される可能性がありますのでご注意ください。
    同じ URL に対する呼び出しが 1 分に 100 リクエストを超えた場合は制限がかかりますので、その場合は少し間を置いて再試行するようにしてください。また、異なる URL の API 呼び出しはカウントされません。

    以上、よろしくお願いします。

    コメントアクション パーマリンク
  • michelle

    お世話になっております。
    お忙しい中、回答ありがとうございます。

    KompiraAPIのコマンドをcurlで実行する際のリスクって何かあるのでしょうか？

    API 実行を行うクライアント (curl など) による動作の切り替えは行っていないため、同じ API 呼び出しを行う限り、API 呼び出しを行うコマンドによって動作が変わるということはありません。

    　→承知しました。リスクはないと解釈いたしました。

    →curlでKompiraAPIのコマンドを実行して、仮にエラーが発生しても既存稼働環境に影響しない想定です。

    この認識については、画面操作では避けられている操作がこちらできてしまうことで、データ整合性に矛盾が生じるなどの悪影響がないかといった意図でのご質問でしょうか。
    　→ご認識の通りです。
    もしそうであれば、データ破損などの心配はございません (※)。
    例えば、必須項目が未指定、表示名が長すぎる、存在しない受信スロットを指定してルールを作成する、ルールによって参照されている受信スロットを削除仕様とするなどといった、成功してしまうと不整合が発生してしまう操作については操作が棄却されて 4xx 系エラーが返り、矛盾が発生しないようになっています。
     
    ※ただし、現状、以下については整合性が取れない結果となる操作が可能となっていますのでご注意ください。ちなみに画面からの操作でも同様です。
    • ランブックのアクションステップからしか参照されていないアクションを削除する
    • ランブックのイベントステップからしか参照されていないスコープを削除する
    →此方も承知しました。
    　既存設定が万が一削除されるようなことがあった場合には、内部の定義間に不整合が起きて
    　環境がおかしくなる可能性がある認識です。
    　初回投稿の通り、今回は既存環境へ（削除は特に行わず）新規登録を行なうので問題ないと
    　解釈しています。
    　※新規登録した設定に不備がある場合は更新（PUT）を実行する予定です。
    　　（DELETEがリスキーなため、間違っても定義のDELETE→INSERTはしない）

    →仮にJSONをもとに登録コマンドを実施してエラーが発生しても、適宜JSONを変更してステータスコード201が帰ってくるまで、コマンド再実行すればいい想定です。登録した定義内容に問題がある場合も然りの想定です。

    こちらは、誤った内容を作成しようとしてエラーが返ってきた後で、少しずつ修正して正しいデータを登録していこうとお考えでしょうか。
    　→ご認識の通りです。

    もし、そのような使い方であってもデータ整合性が壊れることはありませんので問題ございません。
    ただし、同じ URL の API 呼び出しを短時間に大量に試行されると API 呼び出し数制限に抵触し、 429 エラーが返される可能性がありますのでご注意ください。
    同じ URL に対する呼び出しが 1 分に 100 リクエストを超えた場合は制限がかかりますので、その場合は少し間を置いて再試行するようにしてください。また、異なる URL の API 呼び出しはカウントされません。
    　→コマンドの実行頻度に関して制約があるということですね。承知しました。
    　　この点はコマンド実行時の留意事項として認識しておきます。

    ※別件ですが、新規追加用JSONの検証をAPIドキュメントサイトで実施しており
    　エラーが出る箇所がある状況です。
    　この点については別途Pigeonのコミュニティに投稿予定です。

    以上、よろしくお願い致します。

    0
    コメントアクション パーマリンク
  • Kompiraサポートチーム

    お世話になっております。

    ※別件ですが、新規追加用JSONの検証をAPIドキュメントサイトで実施しており
    　エラーが出る箇所がある状況です。
    　この点については別途Pigeonのコミュニティに投稿予定です。

    承知しました。投稿あり次第対応させていただきます。

    よろしくお願いします。

    0
    コメントアクション パーマリンク
  • michelle

    お世話になっております。

    本件は十分確認出来ましたのでクローズとさせてください。

    以上、よろしくお願い致します。

    0
    コメントアクション パーマリンク

サインインしてコメントを残してください。

お探しのものを見つけられませんでしたか？

新規投稿