【今日话题】 分享下api设计过程的规范,优化,及遇到问题和解决方法 - 飞驰的芬兰人 1. HTTP API Design Guide https://github.com/interagent/http-api-design - linbo 2. 还是关心安全性的问题 比如replay attack 怎么办，nonce最好的使用方式 - 飞驰的芬兰人 回: oauth2 https的安全性不行么？ - xiayf 回: 昨天那个nonce就行了? 没有啦, 要么nonce拦截, 要么业务控制不能重复请求, 都差不多的 - twin 回: 可以看一下 Rate Limit. 这是API较为标准的限制方法 - John__ 3. nonce 由客户端每次请求前生成，作为参数一部分传到服务器，然后在服务端存储这个nonce及其使用状态，因此再次使用这个nonce的请求会被拒绝，是这个流程么？ - 飞驰的芬兰人 回: 是啊, 服务端返回数据时也可以带上新的nonce - twin 4. api-design-ebook-2012-03.pdf http://cloud.letv.com/s/OLZRmJ1z - Meow 5. 问: 如果AES，或者其他类似的对称加密，密钥怎么在客户端安全保存？ - 飞驰的芬兰人 回: 一般是rsa和aes结合 公钥 hard code在客户端了 - 黄继 回: 看使用哪种认证方式了，认证用的token和请求的签名可以分开两部分，AES如果用来加密token的话，可以只在服务器端做，客户端不需要做aes加密；请求的签名可以用客户端deviceID来做签名的密钥，deviceID只在登录时用https加密传输一次，之后的请求不传输，这样每个客户端签名密钥是不同的，即使破解了也只对一个客户端有效；比较乱估计没说太清楚呵呵。。。 一直觉得与其客户端做rsa或者aes加密，为啥不干脆直接走https得了，担心现在手机网络https不太好？ - kunsir 6. 问: api定义是需求方先定义，提供方参考协商好；还是提供方定义，需求方协商好。不是开放api - 杨嵩 回: 提供方定义，如果api 供前端调用，协商时提供方需尽可能满足需求方的要求 - 水浸街 回: 提供方是要尽量满足需求方的要求，那么先由提供方定义会不会可能50%或更多都被需求方推翻，不是很悲催 - 杨嵩 回: 提供api 接口还有个前期讨论阶段吧，一起讨论接口方式和大致有哪些接口，全部都定出来再讨论这种方式有问题. 逻辑上的东西在后端实现很方便，在前端就比较麻烦，特别是app 还涉及用户更新问题 - 水浸街 回: 有经验的需求方一定知道自己要什么。 - 杨嵩 7. 看到有些平台定义的API，GET和POST参数格式全部使用json，这样有啥特别的好处么？ - @德武 回: 格式丰富啊 不然咋实现map，dict什么的. array. http的get post参数只能是最普通的一层key value- 仲晨 回: 灵活，参数有变化，不会影响现有系统. 还有就是json是文本格式的，调试方便. 另外一个是json可以和很多语言的数据结构无缝转换 - linbo 回: 这个确实是。之前一个API要实现各种大于小于等于查找，格式搞得有点蛋疼. 如果用JSON就好多了。 - @德武 回: http的get post参数只能是最普通的一层key value - 仲晨 8. API 的认证校验信息你们放在 header 还是get、post参数里面？比如：一些sign , token等全局参数 - @德武 回: 区别不大吧，放get里url会难看些. header的伪造难度略高一点点，不像get直接随便改 - 仲晨 回: 除了调试方便一点外，我也不知道有什么特别的好处。看到有些平台这样设计，把那些认证消息放到header里面。 - @德武 9. 我说一个不优秀的设计吧 公司一个新的app采用了新的api框架 所有的请求都走post 这样app就只有一个请求人口 这样虽然看似简单了很多 不过后面带来了很多问题 最明显的就是不能在nginx层面做缓存 只能在程序里面手动加redis 缓存 - 姚文强 回: 我当初就想这么设计后来发现不太妥…果断还是用基于资源的方式去处理，也就是RESTfull的方式 - 青衫隐_刘 10. 来自HeroKu的HTTP API 设计指南(中文版) http://get.jobdeer.com/343.get - Jason 11. API要实现多种格式的返回以及多字符的支持. 优选JSON格式 - 邵奇 12. Restful和Oauth 是必备方案 - 如末 13. 都说restfull大法好，可国内为什么没有大公司用，如新浪，微信，腾讯，也这是get post Oauth 实战后发现restful，用起来很变扭，资源管理的方式不太顺手 - 林志勇 回: 国内公司业务时间那么长 restful流行的的时候 他们就有了 再改不可能了 - 苹果 回: 很多没用rest,因为他们已经有一套完善的底层了,要转rest吃力不讨好. - twin 14. 我看到的定义 rest就是用来做资源管理的. spring restful很好用 - 苹果 15. 我这边新的模块已经用rest来开发了, 将控制器转为资源之后, 整个架构要比原来清晰 - twin 16. 问: 有没有带版本号功能. 版本号在c控制器上怎么处理 - 林志勇 回: user 对应 app/controllers/User v2/user 对应 app/controllers/v2/User 版本号也对应类名的一部分, 或者大版本重开一个项目 - twin 回: /v1/getUset 之类的文件结构看起来很别扭 - 林志勇 回: 这不是腾讯 的风格么? - 骑马爬树 回: 版本号不是应该放header里吗？ - §时灬光§ 回: 觉得放header里面比较好 - sky 回: header解决不了框架布署问题 - 林志勇 回: 命名,还有一些写法是个槛. 标准的东西总不是最简单的,而是对大部分人最合适的, 所以只能接受下 版本号放URL方便查看调试, 有的文章说header,有的说URL, 只要统一就好 - twin 17. rest性能很差 rest风格会流行 只是因为HTTP服务足够多 大家拿来用更方便 你一个请求 有多少的数据是多余的 protobuf这样的结构为什么会诞生 - 如此玄妙 回: @如此玄妙 api接口,都会有冗余数据. 有的接口可以传select之类的参数来指定返回的字段 - twin 18. 问: 网上说 因为restful是统一资源管理器。url上 都是名词。动词的话 。要用？参数.这个你们怎么看 - §时灬光§ 回: 我们可以认为最简化的URL有这3种格式 resources resources/id resources/id/action resources肯定是名称 action可以动词或名词 例如 shops shops/1 shops/1/edit - twin 19. http://www.ruanyifeng.com/blog/2014/05/restful_api.html - 林志勇 20. 至于restful 所谓的资源 方法的概念. 也并不是很契合. 对于资源类比较合适. 对于各种业务并不合适. 我觉得大家对restful过度崇拜了 就像世界的一切都是对象 一样. 其实就是一种约定 - 如此玄妙 回: 非资源类,就要看抽象能力了 - twin 21. @twin 你用的是什么框架, 你们的框架对这样的URI 是怎么做到命中的. 还是要经过重写URI. 不然不好定位到是哪个controllers module action 吧 例如 shops/1/edit shops 是module? edit 是action 1是参数?另外1的参数一定就是id? - 林志勇 回: 自己写的, 我们从老的改过来, 底层做的最大改动, 是实现url自动转rest资源 对,没法定位,所以一个url匹配出多种资源, 再定位哪种资源存在 https://github.com/twinh/wei/blob/feature/rest-router/tests/unit/RouterTest.php#L539 可以参考这个单元测试的例子 array( 'GET', 'photos/new', array( array( 'controller' = |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
