このブログでは、ModeMapper が Spring Boot API 上のエンティティへのDTOパッピングプロセス自動化でどのように役立つかをサンプルソースを用いて解説しています。また後半では、Auth0を使用して、出来上がったSpring Boot APIをどのように保護し、認可をするかを解説しています。
DTOとは何か？
DTO はデータ転送オブジェクトを表し、リモート インターフェイスで作業しているときに、呼び出し数を減らすことを思いついた設計パターンです。Martin Fowler が [ブログ] (https://martinfowler.com/eaaCatalog/dataTransferObject.html)で定義しているように、データ転送オブジェクトを使用する主な理由は複数のリモート通話を１つのバッチにすることです。
例えば、銀行アカウントのデータを公開する RESTful API で通信しているとしましょう。この場合、現状や最新のアカウント取引をチェックするように複数の要求を発する代わりに、銀行は DTO を返すエンドポイントを公開してすべてを要約することができます。リモート アプリケーションの操作で最も高価なもののひとつはクライアントとサーバーの間の往復時間なので、この粒度の粗いインターフェイスはパフォーマンスの改善に大きく役立ちます。
DTO および Spring Boot API
Java（と Spring Boot）で書き込まれた RESTful API で DTO を使用するもうひとつの利点はドメイン オブジェクト（別名：エンティティ）の実装詳細を非表示するときに役立ちます。エンドポイントを介してエンティティを公開することは、どのプロパティをどの操作を通して変更するかをよく注意しなければ、セキュリティ問題になります。
例として、ユーザーの詳細を公開し、２つのエンドポイントを介してユーザーの更新を承諾する Java API を想像してみましょう。最初のエンドポイントは GET リクエストを処理し、ユーザーデータを返します。そして、２つめのエンドポイントがこれらの詳細を更新するために PUT リクエストを承諾します。このアプリケーションが DTO を利用しなければ、ユーザーのすべてのプロパティは最初のエンドポイント（例：パスワード）で公開され、２つめのエンドポイントはユーザーを更新するときにどのプロパティを承諾するかを精選しなければなりません（例：誰もがユーザーの役割を更新できるわけではありません）。この状況を乗り越えるために、DTO は最初のエンドポイントが対象とするものだけを公開し、２つめのエンドポイントが承諾するものを制限するのに役に立ちます。この特性はアプリケーション内のデータ整合性を保つのに役立ちます。
本アーティクルでは、このような状況を処理するために DTO を利用していきます。後で説明するように、この設計パターンではさらにいくつかのクラスをアプリケーションに導入しますが、そのセキュリティは改善されます。
このブログの続きは、以下のURLで解説をしております。
Spring Boot API で DTO をエンティティへ自動的にマッピングする
Auth0 統合認証プラットフォーム
Auth0はWebアプリやモバイル、APIなどに対して認証・認可のサービスをクラウドで提供している、いわゆるIDaaS (Identity as a Service)ベンダーです。企業がもつWebアプリケーションやAPI, Native Mobile Appなどでユーザー認証や認可、セキュリティを組み込みたいけれでも実装が難しい・・・という方にオススメのソリューションを提供しています。
Githubに様々なプラットフォーム用のサンプルソースを公開
Auth0は今回のチュートリアルで使用したサンプルプログラムをはじめ、様々なプラットフォーム・フレームワーク用のサンプルプログラムをGithubに公開しています。今回紹介したSpring Boot API以外にも多数のフレームワーク用のソースを公開していますので、お試ししてはいかがでしょうか。
[Githubリポジトリ - Auth0] (https://github.com/auth0)
実際にAuth0を利用するには
Auth0のサービスは契約をしなくとも無償で評価(フリートライアル：2２日間)をすることができます。フリートライアルは、Auth0のホームページにアクセスし、画面右上の
をクリックするとトライアル登録が行うことができます。ユーザー登録にはGitgubやGoogle, Microsoftアカウントを使用してサインアップすることできますので、試してみてはいかがでしょうか？