記述することができます。記述するのにも十分柔軟です。プラグインはコアDSLを拡張して、データベースモデル、サービスディスカバリ統合、障害ハンドラなどのマイクロサービスの他の側面を記述できるようにすることができます。記述するための関数の連鎖によって構成されています。デザイン言語はGoで実装されていますがGoではありません。import”は使われていません。使用するのは、はるかに洗練されたコードが得られるからです。透過的に混ぜることができます。さまざまな定義を再帰的に記述するために無名関数を頻繁に使用します。関数は、第1引数として関数の名前を受け取り、第2引数として無名関数を受け取ります。ドキュメント内のこの無名関数もまたDSLであり、APIの追加のプロパティを定義しています。パターンは他の多くのDSL関数でも利用されています。サポートするメディアタイプも定義します。Produces関数は、リクエスト(Consumes)およびレスポンス(Produces)のサポートメディアタイプを定義することもできます。するように、使用するエンコーディングパッケージを指定することもできます。関数で定義できるその他のプロパティがいくつかあります。完全なリストについては、リファレンスを参照してください。設計言語では、実際のエンドポイントをリクエストとレスポンスの詳細形式とともに記述することもできます。エンドポイントのセットを定義します。ある場合のリソースです。関数を使用して記述されます。リソースの例を示します。関数は任意の数のアクションを定義できます。リソースは、共通ベースパス、共通パスパラメータ、およびすべてのアクションで共有されるその他のプロパティを定義できます。関数の引数は可変です)。関数を使用すると、リソース上にファイル・サーバーを定義することができます。ファイルサーバーは、ルートの最後が*で始まるワイルドカードの場合、静的なファイルや指定されたファイルパスのすべてのファイルを提供します。(無名関数を最後の引数として)受け入れます。構文は、アクションのセキュリティスキームを定義するために使用される構文と同じです。リソースを定義しています。送られたリクエストに対して、public/js以下にあるすべてのファイルを返します。基準としたファイルのパスに対応します。仕様を読み出す前に、クライアントに認証を要求するセキュリティスキームを定義しています。デザイン言語はリクエスト・ペイロードやレスポンス・メディアで定義される任意のデータタイプを記述することが可能です。関数を利用して各フィールドを並べることでデータ構造を記述します。関数を利用して配列や配列のフィールドを定義することができます。DSL、を受け取ります。DSLは、次の3つの関数で構成されています。タイプの説明を指定します。タイプフィールドをひとつ定義します。必須のフィールドをリストします。フィールドは必ずそのタイプのインスタンスで存在しなければなりません。おいて特別な役割を果たします。データ構造を定義するために使用される基礎となります。基本的にデータ構造の定義を必要とする場所であれば、タイプ・フィールド、リクエスト・パラメータ、リクエスト・ペイロード、レスポンス・ヘッダ、リクエスト・ボディなどを記述するために使用されます。定義するための構文は非常に柔軟性があり、必要に応じて、少なくにも沢山にも指定できます。<dsl>)最初の引数だけが必須で、他のすべての引数はオプションです。指定可能なタイプは以下です。使用するか、再帰的DSLを使用して定義できます。いう名前を使っていることに注意してください。どちらの構文も受理されます。変数参照の代わりに名前を使用すると、再帰的定義を構築できます。ディレクトリにはタイプの設計と生成されるコード間の対応を示す数多くの例があります。関数は、レスポンス・ボディの形状を表すメディアタイプを記述します。同じメディアタイプの異なるレンダリングを記述することを可能にします。リスト化されたリソースを返すリクエストでは「短い」表現を使用し、単一のリソースを返すリクエストではより詳細な表現を使用します。これらの異なる表現を定義する方法を提供することによって、ユースケースをカバーします。名前が付けられます)。レスポンスに埋め込んでレンダリングされる関連するメディアタイプを表します。ビューを定義していなければならないということです。関数の配下にリストアップされます。関数を用いてすべてのリンクをレンダリングすることができます。関数は、特定の潜在的なレスポンスを定義するためにアクション宣言内で利用されます。レスポンスに本文とヘッダが含まれる場合には、レスポンス・ステータスコード、メディアタイプが記述されます。関数で名前が最初の引数となっているのと同様に、最初の引数にアクションのスコープ内で一意の名前を持つ必要があります。Status(204)})この例およびこのセクションの他のすべての例では、レスポンス・テンプレートを使用しないため、名前を含むレスポンスのすべてのプロパティを定義していることに注意してください。実際には、ほとんどの場合、組み込みテンプレートの1つを使用してレスポンスが定義されます。仕組みを理解する必要があります。関数を使用して指定されます。この関数は、メディアタイプ識別子または実際のメディアタイプの値を第1引数として受け取り、オプションでレスポンス・ボディのレンダリングに使用されるメディアタイプビューの名前を受け取ります。ビューはオプションです。レスポンスのステータスなどに応じて、同じアクションでも異なるビューが返される場合があります。関数の第2引数として提供することができます(これは、以下の対応するセクションで説明する応答テンプレートを使用する場合に特に便利です)。したがって、上記は次のようになります。関数を介して定義されたメディアタイプの識別子に対応しても、そうでなくてもよいことに注意してください。使用してレスポンス・ボディのタイプを定義します。関数を用いて定義されます。定義するのに使用される構文と同じです。定義の一部として、2つの場所で定義できます。Resource定義で定義されたレスポンスは、すべてのリソース・アクションに適用されます。})})デフォルト・メディアタイプの活用リソースはすべてのアクションに対して、デフォルトのメディアタイプを定義することができます。返しメディアタイプを定義しないすべてのレスポンスに使用されます。プロパティ(説明、タイプ、バリデーションなど)を継承します。})})これらの値の定義が変化しても、変更点はただ1箇所ですみます。して定義できるようになっています。そのようなテンプレートは、レスポンス・プロパティのいずれかを定義するために任意の数の文字列引数を受け付けることができます。ステータス・コードに対するレスポンス・テンプレートを提供しているため、単純なケースのテンプレートを定義する必要はありません。ビルトイン・テンプレートの名前は、対応するHTTPステータスコードの名前と一致します。200})まとめデザイン言語にはさらに多くのものがありますが、この概要では、デザイン言語がどのように動作するかについてのひとつの感覚を与えているはずです。言語が自然に感じられるので、設計をすばやく反復して洗練することが可能になります。仕様を、ステークホルダーと共有してフィードバックを収集し、反復することができます。コードをデザインから生成し、それを実装に組み込みます。デザインは、実装に関して常に最新の生きたドキュメントになります。