0

次のクラスが与えられた場合 (注: これらのクラスは議論中ではなく、このように存在するだけです)

class Foo {}

class Bar {}

class Event {

  Foo foo;
  Bar bar;
  String event;

  public Event(Foo foo, String event){
    ..
  }

  public Event(Bar bar, String event){
     ..
  }
}

イベントは Foo または Bar に関連付けられますが、両方に関連付けられることはありません。

REST API を次のようにモデル化しますか (これは、API のユーザーにとって多かれ少なかれ自然に感じられます)。

POST /foo/{FOO-ID}/event
GET /foo/{FOO-ID}/event  --> gets the list of events for FOO with the given id
GET /foo/{ID}/event/{EVENT-ID}

POST /bar/{BAR-ID}/event
GET /bar/{BAR-ID}/event --> gets the list of events for BAR with the given id
GET /bar/{BAR-ID}/event/{EVENT-ID}

または、どちらを好みますか (多かれ少なかれドメイン モデルを反映しています):

POST /event
GET /event?id=123&type=FOO --> gets the list events of for FOO with id = 123
GET /event?id=456&type=BAR --> gets the list of events for BAR with id = 456
GET /event/{EVENT-ID} 
GET /event --> not implemented, it would logically return ALL events(both FOO and BAR), but this has no business meaning

2 つの API のうち、「最も」REST に対応しているのはどれですか? なぜ？

4

1 に答える 1

3

モデルから、Eventそれ自体がエンティティとリソースです。

最初のアプローチは別のメッセージを送信します: その観点から、Eventはまたはのサブリソースであり、存在するためにこれらのいずれかに依存し、その「親」が存在しなくなると、それも存在することを意味します。FooBar

今、あなたのモデルにはそのような関係があるとは思いません。確かに/Eventなしではおそらく意味がありませんが、それだけでも意味があります。明日、s は他の新しいエンティティに関連する可能性があるため、それらに依存する人は、それらを追跡し始めたときに変更する必要があり、その逆ではありません。FooBarEventEventEvent

最後に、クエリ パラメーターの使用は、アルゴリズム リソースやコレクションの "スコープ" フィルターとして一般的です (2 番目のシナリオ)。

FooorBarがクラスとして type のプロパティを持っている場合Event、最初のアプローチを適用できます。

どちらのアプローチも「RESTFul」です。大まかに言うと、REST は HTTP メソッドを適切な方法で使用し、一意の URI を使用して一意のリソースを識別することです。問題は、2 番目のアプローチの方が、モデル (およびその関係) を一連のリソースとしてより適切に表現することです。

于 2013-10-08T15:48:37.120 に答える