Web APIのための規格。
APIリクエストのためのクエリ言語と、APIの仕様を記述するためのスキーマ言語からなる。
必要なリソースのみをクエリに記述するため、結果が予測可能となる。
またひとつのリクエストで多くのリソースを取得できるため、ネットワーク接続が遅い環境下に対応しやすい。

GraphQL

Webページの情報を提供するための標準化されたデータ形式。
Googleがページをクロールする際、より正確に情報を収集できるようになる。
また検索結果に画像などのコンテンツを表示できるようになる。

構造化データ

アプリケーションの実行モデルのひとつで、サーバの運用が不要なモデルのこと。
イベント駆動により、実行に必要なサーバが立ち上がる。
従量課金制によるコスト削減や、サーバのアップデート・スケーリングといった管理が不要になるなどのメリットがある。
これにより開発者がプロダクトの価値向上にリソースを使うことができるようになる。

Serverless

「上位のモジュールは下位のモジュールに依存してはならない」という原則。
下位のモジュールに依存すると、モジュールが変更されたときに影響を受けてしまう。
各モジュールの間に抽象クラスを導入し、各モジュールはこの抽象クラスに依存することで、モジュールを疎結合に保てる。

依存性逆転の原則

「クライアントにとって不要なインタフェースに依存することを強制してはならない」という原則。
依存するインタフェースがふえると、インタフェースの変更による影響を受けやすくなる。
責務に応じてインタフェースを分けるよう設計する。

インタフェース分離の原則

「サブクラスはスーパークラスに置き換え可能であるべき」という原則。
置き換えられないということは、つまりサブクラスへの知識をもつということ。
これは密結合の原因となってしまう。
スーパークラスの知識のみをもち、サブクラスは置き換え可能であるように設計することで、クラスを疎結合に保てる。

リスコフの置換原則

「クラスは拡張に対して開いていて、修正に対して閉じているべき」という原則。
コードの変更は、既存のクラスを修正するのではなく、新しくコードを追加することによって行うよう設計する。
これにより既存のクラスが影響を受けなくなる。

オープン・クローズドの原則

「クラスのもつ責務はひとつであるべき」という原則。
責務が複数あると、その責務の数だけクラスを変更する理由が生じる。
このとき、ある責務に対する変更が、関係ない別の責務に影響を与えてしまう。
複数の責務をもつクラスは最小限にし、クラスには単一の責務だけをもたせるよう設計する。