The general simple operations can basically be simplified into the following
| method | URL | class method | Remark |
| GET | /posts | index | List |
| GET | /posts?key1=xxx&key2=xxx | index | retrieve |
| GET | /posts/create | create | Get creation screen |
| POST | /posts | store | create |
| GET | /posts/{:id} | show | Get a specific resource |
| GET | /posts/{:id}/edit | edit | Get the update screen |
| PUT | /posts/{:id} | update | Update a specific resource |
| DELETE | /posts/{:id} | destroy | remove specific resources |
If there are too many retrieval items and the URL cannot fit, the most convenient way is to POST directly
| method | URL | class method | Remark |
| GET | /posts/searchs/create | index | Search screen |
| POST | /posts/search | search | Search Results Here search is already an action |
But the above doesn't look very RESTful, so what if we submit the retrieval conditions as resources? similar to the following
| method | URL | class method | Remark |
| GET | /posts/searchs/create | create | Search screen |
| POST | /posts/searchs | store | Request conditional submission |
| GET | /posts/searchs/{:id} | show | Search Results |
It feels very awkward, mainly because of the retrieval result. If the retrieval condition is used as a resource, then the third item should return a specific retrieval condition.
Why is the search result of posts?
Work around, what if?
| method | URL | class method | Remark |
| GET | /posts/searchs/create | create | Search screen |
| POST | /posts/searchs | store | Request conditional submission |
| GET | /posts?search_id=xxx | show | Search Results |
This looks good, but it's really a lot of trouble to deal with. If you don't have cleanliness, it's better to use POST directly.
For the problem of deleting multiple resources, the same method can be used (in fact, the essence here is to process the selection item, and it does not matter whether the subsequent deletion or other processing).
| method | URL | class method | Remark |
| POST | /posts/selections | store | selection submission |
| GET | /posts/selections/xxx | show | get options |
| DELETE | /posts/selections/xxx | destroy | delete selected posts |
The last item above is also not RESTful, because according to the semantics, this should be the deleted selection data submitted above, not the specific posts
So the last item can also be changed to this?
| method | URL | class method | Remark |
| POST | /posts/selections | store | selection submission |
| GET | /posts/selections/xxx | show | get options |
| DELETE | /posts?selection_id=xxx | destroy | delete selected posts |
In fact, for ordinary multi-page systems, only GET and POST methods can be used, then other methods are either placed in the URL or in the fields of the Form.
而且，GET以外的所有方法，其实都是POST，所以，对于DELETE其实最终还是POST，那么就直接用POST好了
| 方法 | URL | 类方法 | 备注 |
| POST (用form项目标识为DELETE) |
/posts | destroy | 删除选择的posts |