🛣️ 注文ルート
注文ルートは Express ミドルウェアではなく、SDK コンポーザーです。対応する機能を通じて合成し、注文統合ガイドに示す方法でサービスをマウントしてください。
一覧
詳細
createOrderRoute
実装
エンドポイント: POST /orders
指定された identityId の注文を作成し、応答前に再取得します。
アクセス: 認証済みの管理者、または ID が requestBody.identityId と一致する認証済み ID。
リクエスト: createOrderSchema は、identityId、items、total を含む application/json 本文を必要とします。
パイプライン: createOrder → getOrderById → createOrderTerminator。
成功: 作成された注文オブジェクトとともに 201 を返します。ターミネーターは MongoDB の _id を削除します。
失敗: ハンドラーはリクエストデータの不足(400)、作成失敗(400)、再取得した注文の欠落(404)、またはデータベースエラー(500)を報告できます。認証と認可の失敗は共通およびローカルのバリデーターから発生します。完全なソースを表示
getOrderRoute
実装
エンドポイント: GET /orders/:orderId
1 件の注文を取得し、公開用の応答に正規化します。
アクセス: 認証済みの管理者、または注文を所有する認証済み ID。
リクエスト: getOrderSchema はパスパラメーター orderId を必要とします。
パイプライン: getOrderById → normalizeOrderTerminator。
成功: Express のデフォルト JSON 動作により、注文オブジェクトとともに 200 が生成されます。ターミネーターは _id を削除します。
失敗: getOrderById は ID がない場合に 400、注文が存在しない場合に 404、データベース障害時に 500 を返します。注文がターミネーターまで届かなかった場合も、ターミネーターは 404 をスローします。完全なソースを表示
findOrdersRoute
実装
エンドポイント: GET /orders
検証済みのクエリフィールドから注文を検索します。ページネーションラッパーはルートパイプラインの一部です。
アクセス: 認証済みの管理者、または ID がクエリの identityId と一致する認証済み ID。
リクエスト: findOrdersSchema は、文書化されたフィルターとページネーションのクエリパラメーターを受け入れます。本文はありません。
パイプライン: findOrders → normalizeOrdersListTerminator。withPagination(...) とロギングでラップされます。
成功: Express のデフォルト JSON 動作により、{ data, metadata: { pagination } } とともに 200 が生成されます。各注文から _id が削除されます。
失敗: ハンドラーはデータベース障害を 500 に変換します。パイプラインが対応するリスト形状を生成しなかった場合、リストターミネーターは 500 をスローします。完全なソースを表示
updateOrderRoute
実装
エンドポイント: PATCH /orders/:orderId
注文を更新し、再取得して正規化済みの結果を返します。
アクセス: 認証済みの管理者、または注文を所有する認証済み ID。
リクエスト: updateOrderSchema はパスの orderId と application/json 本文を必要とします。スキーマは空のオブジェクトを許可しますが、ハンドラーは空の本文を拒否します。
パイプライン: updateOrder → getOrderById → normalizeOrderTerminator。
成功: Express のデフォルト JSON 動作により、_id を含まない更新済み注文とともに 200 が生成されます。
失敗: updateOrder は ID または本文の欠落(400)、一致する注文がない場合(404)、変更がない場合(400)、データベース障害(500)を報告します。再取得と正規化処理には、文書化された 400/404/500 の動作があります。完全なソースを表示
deleteOrderRoute
実装
エンドポイント: DELETE /orders/:orderId
1 件の注文を削除します。
アクセス: 認証済みの管理者、または注文を所有する認証済み ID。
リクエスト: deleteOrderSchema はパスの orderId を必要とします。リクエスト本文はありません。
パイプライン: deleteOrder → deleteOrderTerminator。
成功: 204。そのディスクリプターには data がないため、サービスは res.status(204).json(undefined) を呼び出します。
失敗: 削除ハンドラーは ID の欠落(400)、注文が存在しない場合(404)、削除またはデータベースの失敗(500)を報告します。削除フラグがない場合、ターミネーターは 500 をスローします。完全なソースを表示
findOrdersByOrganizationIdRoute
実装
エンドポイント: GET /orders/organizations/:organizationId
再利用可能なデータベースブロックパスを通じて、1 つの組織のページネーション付き注文を検索します。
アクセス: パス内の組織で owner、admin、または member ロールを持つ認証済み ID。
リクエスト: findByOrganizationIdSchema は organizationId を必要とし、ページネーションのクエリパラメーターを検証します。
パイプライン: buildOrganizationIdFilter → buildWithoutMongoIdFindOptions → findOrders → applySpec(...) → orThrow(...)。ブロック検索はページネーションとロギングでラップされます。
成功: Express のデフォルト JSON 動作により、{ data, metadata: { pagination } } とともに 200 が生成されます。buildWithoutMongoIdFindOptions はデータベース射影から _id を削除します。
失敗: orThrow はブロックからの OrderDbBlockError を 500 にマッピングします。バリデーターの失敗はこのパイプラインの前に発生します。完全なソースを表示