restful-like CRUD operation url pattern for nested

问题:

Generally,the CRUD operation url pattern for model can be like this(Suppose the Model is Post):

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

However if there is a nested model "Comment".

And the association of the "Post" and "Comment" is one-many.

So what should the CURD operation url pattern like for comments ?

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

What is the best practice?

---

Update:

It seems that the url for comment should be like this:

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

create: /posts/1/comments

update: /posts/1/comments/1

delete: /posts/1/comments/1

Now I am confused with the update and delete operation.

For update and delete: /posts/1/comments/1

SInce the comment id is specified,so I wonder if the /posts/1 inside the url is necessary?

回答1:

I think the key is whether a comment is "contained" by the post resource. Remember that RESTful urls should be permalinks so under all of your scenarios, the end point to a specific comment(s) must not change. It sounds like it's containted so the url pattern can have the comment nested within the post. If that's not the case (e.g. a comment could move to another post which if nested would change the url) then you want a more flat structure with /comment/{id} urls referenced by the post resource).

The key is if it's a RESTful "Hypermedia API" then like the web it constantly links to the nested or referenced resources. It doesn't rely on the client necessarily understanding the REST pattern or special knowledge as to what end point holds the referenced or contained resource.

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

If a 'comment' is the resource(s) under a 'post' resource:

([httpVerb] /url)

get a post:

[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 a collection of comments within a post:

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

create a comment for a post:

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

edit a comment under post:

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

replace a post:

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

If you have tons of comments per post, you could also consider a paging pattern:

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

then:

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

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

each page would reference the next page, the page count and an array of comments for that page. If you went with a paging pattern then each comment in the array would have a reference url to the individual comment.

If you find yourself putting an action in the url, you're probably doing something wrong. Good read: http://blog.steveklabnik.com/posts/2011-07-03-nobody-understands-rest-or-http

回答2:

You want to use the canonical URL for delete/update, which would be the complete one. More importantly, you shouldn't be exposing your Primary Key values which come from the Database as ids in the public api that is your restful URL space. These values could change in the future based on a database update, restore from backup, or anything else, depending on vendor. And you don't want an infrastructure change making all your URLs invalid if you can help it.

If you're using /posts/{postnum}/comments/{commentnum}, you can number the public comment ids starting from 1 for every post, making for shorter, nicer URLs.