4

私のチームは、物理的な資産の追跡を処理する既存のエンタープライズ アプリケーション用の REST API を設計中です。

私たちのドメイン モデルは非常に複雑で、ルートの設計中にブロックの問題が発生しています。

理想的には、各リソースが複数のビジネス プロセスをサポートするようにしたいと考えています。しかし、リソースの URL を拡張して ServiceStack のルーティング エンジンがどの DTO を使用するかを判断できるようにしない限り、これを行う方法を見つけることはできません。

これが例です。ウィジェットに関連するトランザクションの詳細な履歴を保持し、ユーザーは、さまざまなタイプのトランザクションで表されるウィジェットで複数のタイプのアクションを実行できます。たとえば、widget検査したり、クリーニングしたりできます。どちらも に対する操作/api/widget/{id}ですが、最初の結果は検査トランザクションになり、2 番目の結果はメンテナンス トランザクションになります。同じルートを使用するさまざま/api/widget/{id}な DTO を作成し、要求本文に基づいて正しい DTO を選択したいと考えています。

これは不可能のようです。代わりに、2 つのエンドポイントを作成する必要があるように見えます:/api/widgets/{id}/inspectと/api/widgets/{id}/clean、または同様のものです。

からそう遠くないので、RESTful とはあまり感じられません/api/cleanWidget。リソースの更新というよりは、メソッド呼び出しに近いものです。

これまで説明してきたもう 1 つのオプションは、単一の/api/transactionsエンドポイントを作成することです。これは、API へのほとんどのリクエストでトランザクションが作成されるためです。ただし、これは 1 つのモノリシックなエンドポイントになり、ユーザーは、特定のタイプの要求に対して入力する必要がある数十の可能なデータ属性のどれを把握する必要があります。また、ユーザーがプログラミングするユースケースからはかなりかけ離れています。彼らは、私たちの舞台裏の実装ではなく、やり取りしている物理的なエンティティにもっと関心があります.

2 つの質問:

  1. これについて私たちは間違って考えていますか？これを RESTful な方法でモデル化するより良い方法はありますか?
  2. 私たちの考えが正しければ、リクエストを満たすときにどの DTO とサービス メソッドを使用するかを決定する際に、ServiceStack を使用してリクエスト ボディを考慮する良い方法はありますか?
4

1 に答える 1

4

どう/api/widgets/{id}/inspectionですか？PUT すると検査を開始でき、GET すると検査ステータスを取得できます。

(あなたが言及したトランザクションで) より多くの検査を同時に実行している場合/api/widgets/{id}/inspections、で新しい検査を作成するためにPOST するスキーマを想定できます/api/widgets/{id}/inspections/{id}/。ここでは、GET でステータスを表示したり、DELETE でキャンセルしたりできます。

メッセージ本文に基づいて URL を決定したい場合、1 つのアイデアは/api/widgets/{id}/transactions、メッセージを POST できるリソースを用意することです。/api/widgets/{id}/inspections/{id}/このリソースは、ボディを解析し、ボディが検査を要求した/api/widgets/{id}/cleanings/{id}/場合、またはボディがクリーニングを要求した場合に、照会とともに 201 を返すことができます。

これはほんの一部のアイデアです。ところで、インスピレーションを得るためにRESTify DayTraderを見てみることをお勧めします。

于 2013-03-27T16:22:18.617 に答える