2

これは REST URL の適切な構造ですか?

仮定:

GET /account  <- get list of accounts
GET /account/1234 <- get account 1234

等

アカウント リソースにインターフェースしたいコレクションがある場合、これは良い考えですか?

GET /account/1234/note <- get notes for account 1234
POST /account/1234/note <- add note to account 1234
DELETE /account/1234/note/321 <- delete note 321 on account 1234

特に最後のものは私を一時停止させます。通常、削除するときにエンティティ ID と親 ID の両方は必要ありません。

それとも、このようなものが良いでしょうか？

GET /account-note/1234 <- get notes for account 1234
POST /account-note/1234 <- add note to account 1234
DELETE /account-note/321 <- delete note 321 on account 1234 (b/c note 321 is on account 1234)

しかし、その後、非常に浅い URL セットになってしまいます。

ありがとう

4

3 に答える 3

2

最初の API に問題はありません。ほとんどの場合、RESTful インターフェースの考え方は Web の自然なツリー構造に合わせることであり、最初のアプローチはそれに沿ったものです。また、データストアの暗黙的な制約を抽象化する API の仕事を行う構造にもなります。これは、2 番目のアプローチでは、メモの ID がグローバルに一意であると暗黙的に想定しているためです。これは現在もそうかもしれませんし、今後もそうかもしれませんが、将来的に何らかの大きなデータベースの変更が発生したときに、突然現れて破滅的な結果をもたらすバグでもあります。

私はあなたの最初の計画で行きます。これはおなじみの残りのパターンであり、直感的であり、途中で奇妙な方法で爆発することはありません. また、@ Corwin01 への対応として、クエリ パラメータを最小限に抑えてください。それらはそれほど RESTful ではありません。

于 2012-06-29T17:36:32.767 に答える
0

私は別の質問へのコメントでこの質問を参照しました。そこで得たフィードバックと私自身の調査の間で、これが私が思いついたものです。

まず、質問には欠陥があります。RESTful API、または適切な用語を使用するには、ハイパーメディアAPIに関連するアクションのURLを含める必要があります。これにより、インターフェイスが検出可能になり、変更によって既存のクライアントが破損することがなくなります。したがって、正確な構造の重要性は、私が配置したものよりも大幅に低くなります。後で変更されます。

次に、例のメモはアカウントクエリの一部として取得されます。おそらく次のようになります。

<account>
   ...
   <notes>
      <note>
         ...
         <link href="/account-note/123" rel="note">
      </note>
   </notes>
</account>

クライアントが自分でアカウントにURLをアセンブルすることは決してなく、クライアントは提供されたリンクを使用します。この場合、ノートIDはグローバルに一意であるため、キーを2回含める必要はありません。したがって、質問に対する答えはノーです。最初の例は適切なREST URL構造ではなく、2番目の例の方が優れています。（それでもおそらく最高ではないかもしれませんが...）

于 2012-07-13T18:46:39.927 に答える
-1

私の経験は JAX-RS と Jersey であるため、正確な違いが何であるかはわかりません。

ただし、これは私がすることです：

    @GET
    @Path ("/account/note/{id}")
    public void displayNotes(@PathParam ("accountId") String accountId)
    {
      //do stuff
    }

    @POST
    @Path ("/account/note")
    public void addNote(@FormParam ("accountId") String accountId)
    {
      //do stuff
    }

    @POST
    @Path ("/account/note/delete")
    public void deleteNote(@FormParam ("accountId") String accountId, @FormParam ("noteId") String noteId)
    {
      //do stuff
    }

このようにして、特にユーザーが自分でそこをナビゲートしようとした場合に、ユーザーが見る必要のない、雑然とした紛らわしい URL を作成する必要はありません。これは、アカウントを表示するのには問題ありませんが、404 が返されて理由がわからなくなるため、POST する URL を混乱させる可能性があります。

ユーザーはとにかくそれを見る必要がないので、シンプルにして、ユーザー @FormParams だけにしてください。

于 2012-06-29T17:27:58.040 に答える