@walpurgis 你指的是 options 方法吗，应该跟 Content-Type 没关系吧？

@qiutianaimeili 哈哈哈，新机应该会提前研发的吧

用户能输入 isbn 可行

@ccnccy 坚果手机实现了，不过要靠手机壳的触点

聊聊 JS DOM 变化的监听检测与应用 ——张鑫旭
https://www.zhangxinxu.com/wordpress/2019/08/js-dom-mutation-observer/

远程抓包，有意思～

@shuirong1997 应该是 https://carbon.now.sh/

感动，终于可以看到 Apple 的导航栏效果了
https://i.loli.net/2019/07/31/5d416de74ae6514343.png

requests 的参数里写了 proxies 吗

同，我还以为没有登录呢

请问下这是 2019 届校招，还是 2020 届实习，或者 2020 届校招呢？

请问杭州有岗位吗

IoT 有前端的需求嘛

请问是哪个公司呀，这么菜的前端都能招进去，想来我这个学生也能应聘个实习？
哈哈哈哈哈

分母 + 1644

我还好奇 checkbox 咋偏了，原来设计就是偏的，😄

原来被你注册了，下午看到优惠券想了一会没动手
我刚刚想注册一个这个，之前打算写一个锤子官网的 ui 组件库哈哈哈哈哈。
就选了个别的

不过会不会有被仲裁的可能

因为更好的语义化和遵守规范吧，同理 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 框架都有对应的实现，不必手动去写。