5

連絡先の詳細リソースを含むアプリケーション リソースがあり、連絡先の詳細にはアドレス リソースが含まれているとします。

例えば。

Application
--> Name
--> Application Amount
--> Application Contacts 
--> --> Contact 1
--> --> --> Address
--> --> Contact 2
--> --> --> Address

アプリケーションへの POST を実行するとき、ルート アプリケーションを作成しています。アプリケーション連絡先などのすべてのサブリソースについて、POST を実行して連絡先 1 などを作成します...

私の質問は、アプリケーション = 処理のためにどこかに送信することですが、すべてが入力される前に送信したくありません。つまり、すべての子リソースです。

So the order of submission
1) Create Application Resource --> POST /Application --> Get ID
2) Create Contact 1 Resource --> POST /Application/id/Contacts --> Get ID
3) Create Contact 1 Address Resource --> POST /Application/id/Contacts/id/Addresses
4) Create Contact 2 Resource --> POST /Application/id/Contacts --> Get ID 
5) Create Contact 2 Address Resource --> POST /Application/id/Contacts/id/Addresses
6) DECIDE TO SUBMIT HERE <--- ?? HOW?

ジョシュ

4

3 に答える 3

2

あなたのデザインは RESTful ではありません。あなたのリソースは、おそらくビジネス エンティティと 1 対 1 でマッピングされていますか? これはお勧めしません。ドメイン モデルの中身が外部に公開され、バージョン管理の問題が発生する可能性があるからです。また、このような問題を必要以上に困難にしています - ただし、この設計を強制する REST フレームワークを使用している可能性があります :-( .

覚えておくべきことは、REST のリソースは、外部の世界に見せたいドメイン モデルの要素の抽象表現であり、ドメイン オブジェクトに変換する前にマッピングと変換が必要になる場合があるということです。それらは任意に複雑にすることができます。

ここでの解決策は、POST でアプリケーションを作成し、連絡先とそのアドレスも作成することです。その後、クライアントは、既存の連絡先とアドレス (サーバーがドメイン オブジェクトを逆参照できる) の URL を提供するか、単一のPOST で新しいものを作成するために必要な詳細を提供できます。次に、エンティティーをトランザクション方式で作成して関連付ける責任は、サーバーに委ねられます。新しいアプリケーションを識別する URL への参照を返すだけです。連絡先の URL を知る必要がある場合は、アプリケーションを再取得すると、それらが含まれます。

リソースの MIME タイプが JSON であると仮定すると、最初の POST は次のようになります。 

{
    Name: "Application name",
    Amount: "123.00",
    Contacts: [
        {
            Name: "Contact name",
            Address: {
                HouseNumber: "45",
                StreetName : "Sesame Street"
            }
        }
    ]
}
Return: {href:  “/Application/6789”}

/Application/6789 への GET は、次のようなものを返します。 

{
    Name: "Application name",
    Amount: "123.00",
    Contacts: [
        { mimeType: "application/vnd.com.myStuff.contact+json", href: "/Contact/203" }
    ]
}
于 2013-07-29T07:34:24.627 に答える
0

あなたの質問を正しく理解できたことを願っています。ポイントを逃した場合はお知らせください。いつでも新しいものを提供できます。

そのため、ステップ 1 からステップ 5 までのすべての「サブリソース」がすでに作成されている場合。各ステップで、リソースが正常に作成されたことを確認するための ID が返されます。お気に入り、

POST /Application
Return: {appid:  “/Application/id”}

したがって、ステップ 5 の POST が返されるとすぐに、最後のリソースが作成されます。次に、アプリケーションの「処理」を開始します。

「アプリケーション処理」はリソースと考えることができ、ビジネス アクションは「処理リソースの作成」と「処理結果の確認」です。</p>

これらは、'Processing' リソースでそれぞれ POST と GET を使用してモデル化できます。

処理リソースを作成するには

POST /Application/id/Processing
Return:  {processingid: “/Application/id/Processing/id”}

処理リソースを確認するには

GET /Application/id/Processing/id
Return: {processingid: “/Application/id/Processing/id”, <other info>}

アプリケーション全体を元に戻すには、

GET /Application/id
Return: {all info on the application including processing status as well…}

この助けを願っています。

于 2013-07-22T17:21:38.093 に答える
0

ほとんどの場合、アプリケーションが送信されたかどうかを示す何らかのステータス フィールドが表示されます。この場合、次の 2 つのアプローチをお勧めします。

1) ステータス フィールドを適切な値に設定してアプリケーション リソースに投稿し、意図を示します。

POST /application/654321
status=submitted...

フィールディング論文からの引用は次のとおりです。

「REST コンポーネントは、表現を使用してそのリソースの現在または意図した状態を取得し、その表現をコンポーネント間で転送することにより、リソースに対してアクションを実行します。」

2) 特定のコレクション /submittedapplications にアプリケーションを投稿します。これは、GET を介して送信されたアプリを検索するためにも使用できます。

POST /submittedapplications
id=654321...

アプリケーション リソースを更新するだけでなく、追加の処理手順が必要になる可能性が高いため、POST 動詞を使用して、二重送信が許可されていないことを示す必要があります。

ところで、両方のアプローチは相互に排他的ではありません。同じ API で両方を確実に実装できます。

于 2013-07-23T00:38:33.863 に答える