2

一般に、モデルのCRUD操作のURLパターンは次のようになります（モデルがPostであると仮定します）。

new: /posts/new(get)
create:/posts/(post)
edit:/posts/edit(get)
update:/posts/1(put)
get:/posts/1(get)

ただし、ネストされたモデル「コメント」がある場合。

そして、「投稿」と「コメント」の関連付けは1つです。

では、コメントのCURD操作のURLパターンはどのようにすべきでしょうか？

new: /posts/1/comments/new   or /comments/new
create:?
edit:?
update:?
.......

ベストプラクティスは何ですか？

アップデート：

コメントのURLは次のようになります。

Get one comment for one post: /posts/1/comments/1

create: /posts/1/comments

update: /posts/1/comments/1

delete: /posts/1/comments/1

今、私は更新と削除の操作と混同しています。

更新および削除の場合：/posts/1/comments/1

コメントIDが指定されているので/posts/1、URLの内側が必要かしら？

4

2 に答える 2

4

重要なのは、コメントが投稿リソースに「含まれている」かどうかだと思います。RESTful URLはパーマリンクである必要があるため、すべてのシナリオで、特定のコメントへのエンドポイントを変更してはならないことに注意してください。含まれているように見えるので、URLパターンでコメントを投稿内にネストできます。そうでない場合（たとえば、コメントが別の投稿に移動し、ネストするとURLが変更される可能性がある場合）、投稿リソースによって参照される/ comment / {id} urlを使用したよりフラットな構造が必要になります）。

重要なのは、RESTfulな「ハイパーメディアAPI」の場合、Webと同様に、ネストされたリソースまたは参照されたリソースに常にリンクすることです。クライアントがRESTパターンを必ずしも理解していることや、参照または含まれているリソースを保持するエンドポイントに関する特別な知識に依存しているわけではありません。

http://blog.steveklabnik.com/posts/2012-02-23-rest-is-over

「コメント」が「投稿」リソースの下のリソースである場合：

（[httpVerb] / url）

投稿を取得する：

[get] /posts/{id}
body has a couple options - either it contains the full deep comments array
(depends on how much data, chat pattern)
{
    id:xxx,
    title:my post,
    comments: [...]
}

... or it just contains the post resource with a url reference to the comments e.g.
{
   id: xxx,
   title: my post,
   commentsUrl: /posts/xxx/comments
}

could also have an option like this (or other options to control depth):
[get] /posts/{id}?deep=true

投稿内のコメントのコレクションを取得します。

[get] /posts/{id}/comments
returns 200 and an array of comments in the response body

投稿へのコメントを作成します。

[post] /posts/{id}/comments
body contains json object to create
returns a 201 created

投稿の下のコメントを編集します。

[patch|post] /posts/{id}/comments/{id}
body contains json object with subset of fields/data to update
returns a 200

投稿を置き換える：

[put] /posts/{id}/comment/{id}
body contains json object to *replace*
returns a 200

投稿ごとに大量のコメントがある場合は、ページングパターンを検討することもできます。

{
    id: xxx,
    title: myPost,
    pages:6,
    commentsUrl:/posts/xxx/comments/page/1
}

それから：

/posts/{id}/comments/pages/{pageNo}

{
    nextPage: /posts/xxx/comments/2,
    pages:7,
    comments:
    [ { ...,...,}]
}

各ページは、次のページ、ページ数、およびそのページのコメントの配列を参照します。ページングパターンを使用した場合、配列内の各コメントには、個々のコメントへの参照URLが含まれます。

URLにアクションを入れていることに気付いた場合は、おそらく何か間違ったことをしていることになります。よく読んでください：http： //blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http

于 2012-08-31T02:34:50.340 に答える
0

削除/更新に正規URLを使用すると、完全なURLになります。さらに重要なことに、データベースから取得したプライマリキーの値を、安らかなURLスペースであるパブリックAPIのIDとして公開しないでください。これらの値は、ベンダーに応じて、データベースの更新、バックアップからの復元などに基づいて、将来変更される可能性があります。そして、あなたがそれを助けることができれば、あなたはあなたのすべてのURLを無効にするインフラストラクチャの変更を望まないでしょう。

を使用している場合は、投稿ごとに1から始まるパブリック/posts/{postnum}/comments/{commentnum}コメントIDに番号を付けることができ、より短く、より良いURLになります。

于 2013-02-06T22:24:14.307 に答える