

外部APIと通信するサービスを開発していますが、問題を抱えています

具体的には、  
外部APIのレスポンスのjsonのスキーマがドキュメント通りの正しいものが来る前提の作りになっているんですね

最近、外部APIでのシステムトラブルで、レスポンスボディが存在しないレスポンスが返ってきたときに、nilエラーで異常終了が大量発生してました。  
ソースコードみてみたら、レスポンスボディが存在することと &
レスポンスボディのjsonに処理で使うプロパティが存在する前提（jsonのスキーマが正しい前提）になっていることがわかりました。

なので、外部APIのシステムトラブルによってレスポンスボディが存在しないレスポンスや、（これは実際に起きたことはないですが）必要なプロパティが存在しない、値の型が違うなどレスポンスのjsonの形式が異なっていたりすると、nilエラーなどが起きて異常終了してしまう作りになっているんですね。

そこで考えたのですが、  
レスポンスのjsonのスキーマが正しいチェックする仕組みをいれようかなと思いました。  
レスポンスのjsonのスキーマが異なる場合は専用の例外をraiseして処理をストップして、呼び出し側でrescueして、適切な形で終了するようにハンドリングします。

* * *

外部APIと連携するサービスを作っている方に質問なのですが、  
外部APIのレスポンスのスキーマのチェックはいれていますか？  
それともスキーマが正しくなくてもエラーが起きないようにコードを書いていますか？  
あるいは、外部APIを信頼して正しいスキーマのレスポンスしか来ない前提になっていますか？


CC BY-SA 4.0
2022-06-07T01:53:23.527
89264
2022-06-07T23:54:24.487
40650
question
api
外部APIと通信するサービスを開発していますが問題を抱えています


外部のデータのスキーマのチェックをするかしないかは要件や予算によると思います。

まず前提としてチェックをいれれば入れるほどコストは上がっていきます。  
オブジェクトのプロパティが存在するかどうか毎回チェックを入れて、例外処理もきちんと処理させて対応していくとなると当たり前ですけどコード量が多くなり、テスト設計をすると条件が多くなり検証工数も大きくなります。

例えばすごく致命的な処理でそれがエラーにより止まってしまうと、全体の売り上げやサービスまたは人命に影響がある場合は、間違いなくチェックを厳密にします。一滴たりともエラーを出したくないサービスを止めたくないという場合は予算をかけてエラー処理を記述します。

ですが市場のほとんどのサービスであればそこまで厳密なものを求められることは少ないです。  
そうなると責任範囲の確認が重要になります。

外部APIの仕様によりますが、向こうがどういったことを返す可能性があるかはきちんとヒアリングしておく必要があります。空を返してしまう可能性があるのか？JSON以外のテキストを返す可能性があるのか？レスポンスヘッダーは間違いなく正しいものが返ってくるのか？  
この辺りは最初に確認しましょう。

なので、JSONのSchemaが変わってしまうような不具合やJSONが返ってこないような障害が起きた場合は、外部APIの責任なので、自分の製品では規約や免責で回避しておくことが重要です。

ただし、APIの場合は向こうのサービスは問題なくても自社のネットワークの問題でネットワークの外に出れないという障害が発生する可能性は十分あります。

そのため、自社のネットワーク障害というリスクに対してコストをかけて  
レスポンスのヘッダーが正しく取得できているか？返されたものが存在しJSONであることをチェックする。保守を手厚くする（エラーの検知と通知、およびサービスの復帰）ことで対応することもあります。これは自社のサービスの責任範疇になるのでリスクマネジメントが必須です。

何事もそうですがどういったリスクに対してどの程度コストをかけることができるプロジェクトなのかこれをプロジェクトプロダクト毎に見極めて、正しくマネジメントして開発をする必要があります。


CC BY-SA 4.0
2022-06-07T23:54:24.487
89274
2022-06-07T23:54:24.487
22665
89264
answer