设计RESTful的API
一般的简单操作，基本上都能简化为一下几种
| 方法 | URL | 类方法 | 备注 |
| GET | /posts | index | 一覧 |
| GET | /posts?key1=xxx&key2=xxx | index | 检索 |
| GET | /posts/create | create | 作成画面取得 |
| POST | /posts | store | 作成 |
| GET | /posts/{:id} | show | 取得特定资源 |
| GET | /posts/{:id}/edit | edit | 更新画面取得 |
| PUT | /posts/{:id} | update | 更新特定资源 |
| DELETE | /posts/{:id} | destroy | 削除特定资源 |
如果检索项目特别多，URL放不下的情况，最方便的做法就是直接POST
| 方法 | URL | 类方法 | 备注 |
| GET | /posts/searchs/create | index | 检索画面 |
| POST | /posts/search | search | 检索结果 这儿search已经是表示动作了 |
但是上面看起来很不RESTful，那么我们把检索条件也作为资源提交上去呢？类似于下面这种
| 方法 | URL | 类方法 | 备注 |
| GET | /posts/searchs/create | create | 検索画面 |
| POST | /posts/searchs | store | 検索条件提交 |
| GET | /posts/searchs/{:id} | show | 检索结果 |
感觉很别扭，主要是检索结果这项，如果把检索条件作为资源的话，那么第三项返回的应该是特定的检索条件才对，
为什么会是posts的检索结果呢？
变通一下，如果这样呢？
| 方法 | URL | 类方法 | 备注 |
| GET | /posts/searchs/create | create | 検索画面 |
| POST | /posts/searchs | store | 検索条件提交 |
| GET | /posts?search_id=xxx | show | 检索结果 |
这样看起来还不错，不过处理起来确实麻烦了很多，如果不是有洁癖的话，直接用POST就比较好了。
对于删除多个资源的问题，也可以用同样的方法(实际上这儿本质是处理选择项，至于后续是删除还是其他处理，都没关系)。
| 方法 | URL | 类方法 | 备注 |
| POST | /posts/selections | store | 选择项提交 |
| GET | /posts/selections/xxx | show | 取得选择项 |
| DELETE | /posts/selections/xxx | destroy | 删除选择的posts |
上面最后一项同样不RESTful，因为按照语义，这个应该是删除的上面提交的那个选择数据，而不是具体的posts
所以最后一项也可以改成这个？
| 方法 | URL | 类方法 | 备注 |
| POST | /posts/selections | store | 选择项提交 |
| GET | /posts/selections/xxx | show | 取得选择项 |
| DELETE | /posts?selection_id=xxx | destroy | 删除选择的posts |
实际上，对于普通的多页面系统，只能用GET和POST方法，那么其他方法要么就放到URL里，要么就放到Form的字段里。
而且，GET以外的所有方法，其实都是POST，所以，对于DELETE其实最终还是POST，那么就直接用POST好了
| 方法 | URL | 类方法 | 备注 |
POST (用form项目标识为DELETE) | /posts | destroy | 删除选择的posts |
相关推荐
momode 2020-09-11
思君夜未眠 2020-09-04
行吟阁 2020-08-09
表格的现在还是较为常用的一种标签，但不是用来布局，常见处理、显示表格式数据。在HTML网页中，要想创建表格，就需要使用表格相关的标签。<table> <tr> <td>单元格内的文字</td> ...
gufudhn 2020-08-09
世樹 2020-11-11
SCNUHB 2020-11-10
bleach00 2020-11-10
FellowYourHeart 2020-10-05
jessieHJ 2020-08-19
末点 2020-08-03
nimeijian 2020-07-30
好记忆也需烂 2020-07-28
zlsdmx 2020-07-05
tomson 2020-07-05
tianqi 2020-07-05
onlykg 2020-07-04