因为更好的语义化和遵守规范吧，同理 http 状态码也是一样，1xx - 5xx 都有不同的含义。

以 restful 举个简单的例子，把你要操作的对象当作资源：
GET 方法获取这个资源，get /books/1 | get /books?page=1，200 表示成功找到
POST 方法创建一个资源，post /books，201 表示成功创建
PUT 方法更新一个资源，put /books/1，200 表示更新成功
DELETE 方法表示删除一个资源，delete /books/1，删除成功，返回 204，不必返回内容

此外还有 patch 部分更新资源等等方法，401 未授权等等状态码，分别表示不同的含义。

这样在一个 URL 端点上就能完成资源的增改删查四种操作。

个人理解就是既然规定了这么多，那就物尽其用呗。

一般对外开放的 open api 会规范一些，比如 https://developer.github.com/v3/ ，对内的做得比较好的，参考 https://h5.ele.me

但是，实际操作中往往还是按照团队的规定和喜好吧。
我们有几个项目，所有 API 一律使用 POST 方法，语义就以 URL 来做，比如：
post /get_books_info 查询资源
post /add_book 创建资源
....
返回状态码一律为 200， 靠 body 中的 err_code 来判断请求是否成功。

当然，为了加密等需求，也有许多更奇怪的方案，比如我校 app，所有均为 get，请求体加密成字符串放到 url 中，公开产品比较著名的就是网易云音乐了 ， 全为 post，body 是加密后的参数
https://github.com/darknessomi/musicbox/wiki/%E7%BD%91%E6%98%93%E4%BA%91%E9%9F%B3%E4%B9%90%E6%96%B0%E7%89%88WebAPI%E5%88%86%E6%9E%90%E3%80%82

两种方案各有优缺点，业务复杂的时候 restful 还是有点吃力的，不必完全去遵守哪一种。文档写的好，能让 api 的使用者明白、方便就行了（微信真是。。。。。

最后，回到你这个问题，编写 web api 时候并不是每一种方法都要写，就如 4 楼所说，http 是有一个专门的状态码来表示不支持该请求方法的，405 Method Not Allowed。当客户端使用了不支持的方法来请求，就返回这个状态码好了。

当然，如果有跨域等需求，像 options 这种方法还是要实现的，不过直接在 nginx 层做或者一般的 web 框架都有对应的实现，不必手动去写。

可惜浏览器兼容性太差

https://caniuse.com/#search=backdrop-filter

恕我眼拙，你贴出来的配置文件没有反代的部分啊

location / {

proxy_pass http://127.0.0.1:5000;

}

文档中描述的功能不足以实现需求的时候，就去翻翻源码有什么非公开的 Api。

然而人家就那么设计的，看了也没得用。

@autogen #21 感谢详细讲解。这样的话是标准的一对多关系。当上传来图片的时候在图片表插入一条记录，weibo_id , order 设为 null，发布微博的时候再批量修改这几条图片记录的 weibo_id 和 order。新发布的时候逻辑很清晰。

当修改的时候，对比当前图片数组与新的图片数组，需要分几种情况：
1. 顺序变，更改 order
2. 有增加，将 weibo_id 插入增加的那张图片的记录，并重新修改 order
3. 有删除，将删除的图片那条记录 weibo_id 设为 null 或删除这条记录，并重新修改 order

这样修改的时候，操作会比较复杂一点。

希望我没理解错误。

@kangzai50136 #17 抱歉，我以为你是存储的 微博-图片表。

如果表结构为
- weibo_id
- pic_id
- order

更改顺序或增删图片，就要操作多条记录

@kangzai50136 #14 那您修改图片顺序的时候，操作量不会很大。


@zhengwhizz #15 嗯嗯，一起上传的话，如果九张图，考虑到速度问题，还是选择了先上传图片。因为实际需求比微博的表单字段要多很多。

@kangzai50136 #11 请问您的需求中需要保存顺序吗，是怎么解决顺序问题的呢？


@DavidNineRoc #10 感谢您的耐心解答，对于你第二点中的解释，“前端选择图片 -> 云存储(本地存储)保存返回 url 数组”，在返回 url 数组的时候，因为图片会有其他信息和多个 url，这时后端是不是要设置一个过期时间缓存一下，当微博发送的时候再插入数据库，如果用户不发表了，这些图也就过期了。

@emeab 嗯嗯，我觉得如果按照 1 的话顺序应该加个字段。

其实还有编辑功能，编辑的时候有可能会修改顺序，或者增删图片。选方案 1 的话工作量还挺大的。

睡觉前又想到一个方案。

图片表增加一个 status_id 字段，上传图片的时候为 null，当发布微博的时候再将微博 id 插入进去。

顺序问题还要想想。

对不起，图裂了，请看这张图

https://s2.ax1x.com/2019/05/03/ENDKz9.png

导入 字符分隔值文件读写库

类 字符分隔值文件处理：

装饰为静态方法
定义函数 读文件到数组（文件名）
.......................

看看浏览器有没有自动填充

https://ws2.sinaimg.cn/large/75d79f01gy1g2a9y18mogj20g00b5wfn.jpg

这 tm 也太逗了

更新后试了下，提示很多歌提示

https://ws2.sinaimg.cn/large/75d79f01gy1g2aa4mtpwuj20jy08xdgk.jpg

无会员

https://ws2.sinaimg.cn/large/75d79f01gy1g23x4pudqsj213w0g4dia.jpg

看了一下，基本上都是服务器请求 Api 再返回给客户端，相当于做了下中转？
感觉属于一种资源的“浪费”，还有有些 Api 若有频率限制如何解决？
提个建议，不如把这些 Api 的接口、参数整理一下，**直接**调用更方便一些。

参考下这个项目：
https://github.com/jokermonn/-Api

哈哈哈哈哈哈哈哈哈哈，笑死我了