1 年ほど前、私のチーム(多数の社内アプリケーションの構築と管理、および他の部署のアプリケーションで使用するツールやベストプラクティスの提供を担う InterSystems のアプリケーションサービス部門)は、Angular/REST ベースのユーザーインターフェースを元々 CSP や Zen を使って構築された既存のアプリケーションに作りこむ作業を開始しました。 この道のりには、皆さんも経験したことがあるかもしれない興味深いチャレンジがありました。既存のデータモデルとビジネスロジックに新しい REST API を構築するというチャレンジです。 このプロセスの一環として、REST API 用に新しいフレームワークを構築しました。あまりにも便利であるため、自分たちだけに取っておくわけにはいきません。 そこで、Open Exchange の で公開することにしました。 今後数週間または数か月の間に、これに関する記事がいくつか掲載される予定です。それまでは、GitHub のプロジェクトドキュメント))に用意されたチュートリアルをご利用ください。 はじめに、設計の目標と意図についていくつか以下に示します。 すべての目標が実現したわけではありませんが、順調に進んでいます! ## 高速開発とデプロイ REST アプローチは、Zen と同じアプリケーション開発のクイックスタートを提供し、一般的な問題を解決しながら、アプリケーション固有の特殊なユースケースに柔軟性を提供する必要があります。 * REST アクセスへの新しいリソースの公開は、Zen DataModel と同じくらい簡単である必要があります。 * REST リソースの追加/変更には、アクセスされているレベルでの変更が必要です。 * REST による永続クラスの公開は、継承と最小限のオーバーライドで行えるべきですが、ハンドコーディング相当の機能もサポートする必要があります。 (これは、%ZEN.DataModel.Adaptor と %ZEN.DataModel.ObjectDataModel に似ています。) * エラー処理/レポート、シリアル化/逆シリアル化、検証などに関する一般的なパターンは、各アプリケーションの各リソースに対して再実装する必要があってはいけません。 * SQL クエリ、フィルタリング、順序付け、および高度な検索機能とページネーションのサポートは、各アプリケーションに再実装するのではなく、組み込みである必要があります。 * REST API はオブジェクトレベル(CRUD)でだけでなく、既存の API/ライブラリのクラスメソッドとクラスクエリに対しても簡単に構築できます。 ## セキュリティ セキュリティは、付け足しで行うものではなく、設計/実装時に断定的に決定するものです。 * REST 機能がクラス継承によって取得される場合、開発者が能動的にアクセスが必要な人とアクセス条件を指定するまでリソースにアクセスできない動作をデフォルトとします。 * SQL 関連機能の実装を標準化することで、SQL インジェクション攻撃の標的を最小にします。 * 設計には OWASP API トップ 10(参照: [https://owasp.org/www-project-api-security](https://owasp.org/www-project-api-security/))を考慮する必要があります。 ## 持続可能性 アプリケーション設計の統一性はエンタープライズアプリケーションエコシステムにおいて強力なツールです。 * 多様なハンドコーディングされた REST API と実装を蓄積するのではなく、一連のポートフォリオを通じて外観が似通った REST API を作成しなければなりません。 この統一性により、次が達成されなければなりません。 * 共通のデバッグ手法 * 共通のテスト手法 * REST API に接続するための共通の UI 手法 * 複数の API にアクセスする複合アプリケーションの開発の簡便性 * REST を介して提供または受け入れられるオブジェクト表現のエンドポイントと形式は、エンドポイントに基づいて API ドキュメント(Swagger/OpenAPI)を自動的に生成できるほど十分に定義されている必要があります。 * 業界標準の API ドキュメントに基づき、サードパーティまたは業界標準のツールを使用して、クライアントコードの一部(REST 表現に対応する typescript クラスなど)を生成できるようにします。