八哥 置顶2019-09-18早期后台接口之间调用Web Service时用的SOAP协议多，比如订单和供应商之间接口调用等。后续RESTful风格更轻量级，开发者工程师更愿意使用。配合api文档，解决了联调过程中，接口没有定义规范等问题。
userName不是唯一的，实际无法完成删除，delete是一个删除操作，不应该暴露在URL里面。
应该是:/users/xxx。xxx是userId，然后请求的method设置为：DELETE。展开作者回复: 感谢回答！回答正确。
第一个问题属于开放性的，当然，也有很多可供比较的其它方面。
对于删除用户的接口设计，回答得非常全面：
（1）动作要以 HTTP 方法体现出来，而不是放在 URL 里面；
（2）要使用 userId，而不是 name，userId 才是唯一的。
（3）资源使用复数“users”，完全正确。 7
2019-09-18RESTFUL设计删除单个用户"http://xxx/deleteUser?userName=James"的问题如下：1)get/put/post/delete不是应当接完后再加/再去跟具体的么？至少应当改成"http://xxx/delete/userName/James"
2)其实这种具体的值不应当直接放到这里：我记得当年自己做开发的时候就不会允许暴露账号信息的
其实那里直接写到"http://xxx/delete/userName"样子就不会再在HTTP里面看到了；当年经典的SQL注入不就是全部明文写在里面了么。
REST架构和风格这块我在开课时曾说过希望能改善自己Coding的问题：按照老师REST那块的Coding演示：其实username=James应当放到Content-Type: application/json里面并且写出username:James;HTTP部分只到"http://xxx/delete/username"这样就OK了；翻阅了一些网站现在的写法，发现大多类似；具体答案：等待老师的揭晓。
谢谢老师的分享：期待下节课的内容。
展开作者回复: 感谢回答！
严格来说，行为应当放到 HTTP 方法中去，而不是 URL 中。还有使用 userName 本身的问题，你可以看一下另一位朋友的回答。当然，现在不少接口其实并不是很符合 REST 风格的，方法放在 URL 中就是其中一个方面。至于不允许暴露账号信息是特殊的业务需要，能想到这一点非常好，但它并非 REST 的要求。 3
2019-09-26「，至于 HTTP，它是 REST 风格的重要载体。重要，但不是唯一，因为载体并不只有 HTTP 一个，比如还有 HTML 和 XML，」http与html xml这里适合放在一起类比吗？这里他们是阶段组合的关系，而非可相互取代的关系？若老师看到，望解答，谢谢作者回复: 好问题。
我解释一下文中的含义：你理解得没错，它们是互相组合的关系，而非取代的关系。
进一步展开说，当载体体现的是它上面的数据的时候，就是 HTML、XML 或者 JSON 它们关心的了。我们在讲 REST 的时候，特别是设计 REST 风格的接口的时候，我们并不是到 HTTP 层面就戛然而止了，我们还会继续设计消息体，这就往往会提到这三者之一。 1
2019-09-20RESTful 风格的API：（系统接口：正交化，统一化/标准化，结构化）
1.正交化资源（名词）和动作（动词）
2.资源的描述要统一（URI），先模块/位置，再资源/标识符，最后可以附加简单的参数（?x="y"#label）。复杂的参数应当结构化，通过Header传递
3.动作要标准化（AEMR等有限集合），个性化需求可以通过API查询接口获取/协同
函数风格的API：（模块接口：正交化，结构化，模型化）
1.动词作为函数名，名词作为参数（正交化）
2.常见类型的参数（数量也不能太多）可以简单罗列，复杂的参数应当结构化为对象来传递，参数太复杂或数量太多时就需要考虑拆分函数（结构化）
3.函数存在于模块里面，它的目的是实现DSL（模型化），自然不能标准化。但它操作的对象相对单纯，因此函数语义（主要通过通过函数名称表达）相对更加明确，可以实现言简意赅展开作者回复: 👍
1 1
2019-09-20（1）两种都用过，之前在银行类使用过webservice，就是很典型的，就是约定好字段一个不多一个不少按照WSDL上来。后面公司用的是Rest，看文档反正你要的我都给你了，需求变更也不怕反正能满足你就是了。
（2）参数选择不对，命名不规范，用户名称不是唯一的很可能重复，即使是唯一的，博大精深的汉字也能教育你，可能某个系统编码库不全，一些少见的字造成不必要的麻烦，什么飞龙在天的䶮可能结果是不一样的。还有接口命名，先是模块再是功能，如users/deleteUserById?id=XXX。看过一本书给的建议命名是不要怕长，总比看上去提示太少一脸懵逼强。
老师对命名有没有理解，之前没注意过现在虽然有意识的修改，争取见词知意，但还是有些没做好，像前一阵包名有大写字母和下划线被人吐槽看着蛋疼。展开作者回复: 接口命名方面，没有统一的标准，但你可以看看第五讲扩展阅读的 AnyAPI，看看其他人是怎么做的，大多数接口服务的命名风格是一致的。
1
2019-09-18米用过，但如果米理解错的话，RESTful风格是用URI标识要操作的资源，用HTTP请求行为表示要对资源执行的动作，所以delete这个“行为”不应该出现在URI里吧，总不能get这个用户和del这个用户操作的还是不同的资源？作者回复: 对，行为不能出现在 URI 里面，你可以看一下另一位朋友 的回答。
1
2019-11-17为什么删除操作是幂等性的...作者回复: 在使用唯一的 id 去删除指定资源时，删除多次和删除一次效果一样
- 2019-09-26关于幂等性，文中说的是服务端的数据状态不变，但是「从表格中你可以看到，创建资源单位不是幂等的，执行多次就意味着创建了多个资源单位，而其它操作都是幂等的。」这个是按照数据量来衡量的吗，如果是这样，那删除操作怎么是幂等的？望老师看到解答。
作者回复: 好问题。
我来解释一下文中的意思。“幂等”的效果是，执行了多次和执行一次的效果一样，而 REST 通常的删除设计都是基于唯一 id 的，因此从这个角度来说，删除多次，确实和删除一次是一样的，因为只有一次是完成了真正的删除。
但是创建就不是了，因为创建的时候，REST 的设计往往是不提供这个唯一 id 的（唯一 id 是服务端自动生成的），那么如果提交多次，就变成了创建了多个对象。 2 
2019-09-19目前外包在银行做供应链业务，soap与restful混用，新接口基本都不用soap了，像soap这种结构相对复杂的方案会逐渐被淘汰吧，restful更简单明了
2019-09-19之前一个项目 ws和rest都有用到，rest是自己项目前后台请求使用，ws是请求第三方的接口使用。只是停留在使用阶段 还没有深入的了解过，借着这一课 认真学习下。
2019-09-18项目中用的基本上都是REST，我觉得用SOAP的只有以前遗留下来的代码了。作者回复: SOAP 还是常有使用的，特别是一些电信软件、传统软件等领域。当然，确实 REST 更常见。
2019-09-18项目中基本上用的都是restful。soap用着别扭作者回复: 为什么别扭？:)
1