1

シナリオを考えてみましょう。認証されていない不明なユーザーがnerddinnersのリストを見て、特定の夕食会に行き、名前と電子メールを入力して[出席]をクリックします。これにより、2つの結果が得られるはずです。ユーザーを作成し、そのユーザーのDinnerAttendRequestを作成します。ユーザーには、参加したいディナーのprog言語プロパティに設定されたFavProgLanguageというプロパティもあります。

APIと通信する単一ページのJavaScriptアプリであると仮定すると、2つのアプローチが思い浮かびます。

1）クライアントで、ユーザーFavProgLanguageを設定してから、名前、電子メール、およびfavproglanguageを指定して/userにPOSTしてユーザーを作成します。作成したUserIdとPOSTをDinnerIdとUserIdとともに/DinnerAttendRequestに使用して、DinnerAttendRequestを作成します。

2）Name、email、dinnerIdを使用して/ somenameにPOSTし、サーバーでdinnerIdを使用してユーザーのfavproglanguageを入力します。ユーザーを作成し、useridを使用してDinnerAttendRequestを作成します

最初のアプローチはより自然でRESTfulに見えますが、favproglanguageを計算するロジックが少し複雑な場合、すべてのAPIコンシューマーはそのロジックを実装する必要があり、2番目のアプローチではコードがサーバーに1回だけ書き込まれます。

どちらがより良いアプローチですか？2番目のアプローチはRESTfulですか？

4

1 に答える 1

3

最初の設計では、ロジック、ワークフロー、およびfav langの決定に負担がかかります。これにより、ユーザーの作成と予約の処理が困難になり、クライアントアプリが調整する必要があります。fav langロジックは重要なビジネスルールのように聞こえますが、これも理想的にはサーバーに置いて再利用する必要があります...

次のようなリソースを検討してみませんか。

  1. 夕食例：{"名前"、"日付"など}
  2. 予約例：{"user" {NESTED USER RESOURCE}、"bookingStatus"など}
  3. ユーザー例：{"email"、 "name"、"favlang"など}

いくつかの例のURL

  1. /dinners/{uid}
  2. /dinners/{uid}/bookings
  3. / users / {uid}

基本的に、ネストされたユーザーリソースを含む予約リソースを夕食の予約URLにPOSTし、ユーザーが存在するかどうかを確認するロジックを実行し、必要に応じて作成し、トランザクションでお気に入りの言語を更新します。

したがって、予約を作成するには、予約リソースをPOSTします。

{
    "user": {
        "email": "john@doe.com",
        "name": "name"
    },
    "bookingStatus": "requested"
}

/dinners/{uid}/bookingsへ

そして、次のような応答で201が作成された応答を期待します。

{
    "uid": "4564654",
    "user": {
        "uid": "1234564",
        "email": "john@doe.com",
        "name": "name",
        "favLang": "C#"
    },
    "bookingStatus": "booked"
}

明らかに、プロパティは主に単なる例ですが、うまくいけば、これはいくつかの概念を示し、単一のPOSTがRESTfulと見なすことができることを示しています...

于 2012-09-14T08:06:06.747 に答える