⇧ IT系の技術的な情報の検索については、品質を改善するのは難しそうな気がしますな...
IT系の技術的な情報については、公式のドキュメントとかもイケてないからして、手の施しようがないという気もするが、頑張って改善して欲しいのだが...
ちなみに、
Google Cloud accidentally deletes UniSuper’s online account due to ‘unprecedented misconfiguration’
⇧ Google Cloud側で誤ってUniSuperのアカウントが削除されたらしいのだけど、UniSuper側でサービスのバックアップを取っていたらしく、復元できたということらしい。
クラウドで「事業継続計画（BCP：Business Continuity Plan）」は破綻する可能性もあると...
まぁ、人災であるならば、オンプレミス環境でも起こり得る問題ではありそうなので、サービスのリソースを退避する場所が肝ということですかね。
UniSuper側でバックアップを別のシステムに退避するようにしていた方、偉大過ぎますな。
う～む、クラウドサービスプロバイダーをどこまで信じれば良いものか...
JSONのキーが削除されてる場合にJavaのDTOにデシリアライズを上手くできるんだっけ？
とりあえず、Spring Web MVCでバリデーションする際のパターンとして、
- Spring Web MVCのコントローラーのメソッドの引数にアノテーションを付けてバリデーションする
- Spring Web MVCのコントローラーのメソッドに入ってからでバリデーションする
- Service Layerでバリデーションする
の3つがあるのかなと思うのですが、いずれにしろ、外部からリクエストされてきたデータをJavaのDTO（Data Toransfer Object）などに変換することで、DTOの各フィールドに付与してるバリデーション用のアノテーションでバリデーションするってのがメジャーな方法なのかなと。
つまり、バリデーションするには、JSONからJavaのDTO（Data Toransfer Object）にデシリアライズが必要になってくると。
JSONからJavaのDTO（Data Toransfer Object）のデシリアライズの流れのイメージとしては、
⇧ 上記サイト様のイメージ図が分かりやすいかと。
上図のJava Objectが、バリデーション用のアノテーションが付与されたDTO（Data Toransfer Object）に該当すると。
で、
⇧ 何やら、JSONのキー自体を削除できてしまいますと。
JSONのキーが削除できるということで、少し気になってくるのが、JSONからJavaのDTO（Data Toransfer Object）にデシリアライズする際にエラーとかにならないのかと。
そのあたり、Jacksonが良しなに対応してくれるのかどうかが分からない...
リクエストを受信する側で考慮する問題ではあるのですが、気になったので調べてみることに。
Spring Frameworkのドキュメントを見る限り、
⇧ Spring Web MVCは、デフォルトでJacksonライブラリが有効になっているらしい。
⇧ 上記サイト様がJacksonによるJSONとJavaオブジェクトの相互変換についてまとめてくださっています。
で、
の内、「1. JSONの中に、デシリアライズ後の Java オブジェクトに存在しないプロパティがある場合」については、
@JsonIgnoreProperties(ignoreUnknown=true)
⇧ 上記のアノテーションをJavaのDTO（Data Toransfer Object）クラスに付けていれば良いらしい。
で、今回、気になっている「2. JSONの中に、デシリアライズ後の Java オブジェクトに存在するプロパティが無い場合」のケース、つまり、JSONからキー自体が削除されている場合におけるデシリアライズでエラーにならないのか？
これについて、言及しているネットの情報が見当たらないのだけど、Microsoft Copilotの「より厳密に」モードで質問してみたところ、「2. JSONの中に、デシリアライズ後の Java オブジェクトに存在するプロパティが無い場合」のケースについても、
@JsonIgnoreProperties(ignoreUnknown=true)
⇧ の対応でデシリアライズでエラーにならないようにしてくれるという回答だった。
まぁ、実際に動作確認できていないのでMicrosoft Copilotの回答は全く信用できないわけなのだけど、相変わらず、Java関連のドキュメントはカオスだなぁと...
そもそも、IF定義書のフォーマットのままやり取りすれば良いと思うのだけど、非必須な項目で設定される値が無いケースでJSONのキー自体を削除するって方針になるかもしれないということで、JSONのキーがJava DTOのフィールドより少ないケースでデシリアライズでエラーにならないのか調べてはみたものの、これといった情報が見当たらないんだが...
とりあえず、今回、送信する側なので、JSONからのデシリアライズを気にする必要は無いのだけど、JSONのキー自体を削除するケースが一般的なのかどうかが分からない...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
