关于 RESTFUL API，求解释

[edison111cry]

看大家讨论 RESTFUL API 比较多，网上搜了一通也是一头雾水。这个东西是指一种思想，还是一种标准，还是啥？

比如我写服务器端给 APP 写增加评论的接口，

http://www.test.com/index.php/Comment/addComment/uid/1234/content/good

这个 URL 我会发给 APP ，然后告诉他们，传用户的 uid 以评论的内容 content 。 返回 json 数据里 code 为 1 是成功，为-1 不成功。

APP 他们就按照这个格式调用就可以了。我觉得一般公司做项目都是这种流程吧？

这跟 RESTFUL API 有什么区别呢？

[akinoniku]

是一种风格，并不是强制性的，其实还蛮灵活，因为永远没有最佳实践。。

rest 成功与否一般用 http status 表示。但如果你非要说你那也是 restful ，我觉得也是 ok 的

[FinnBai]

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

这是我读过的 RESTful API 实践 最好的一篇文章, 也是之前的 RESTful 讨论帖子中有 V 友贴出的.

如果楼主想了解下区别的话 对比文章中的例子,与说明,能够很好的理解

[Kilerd]

如果用 REST 风格重写你这个借口的化 应该是这样的：

POST http://www.test.com/comment {"uid": 1234, "content": "good"}

btw ， 你这里的 index.php 是什么鬼，不 rewrite 一下？？

[ChefIsAwesome]

你觉得云里雾里，是因为你看到的都是怎么实现 restful 的文章。
你要找的是一篇文章，告诉你 restful 能解决什么问题，别的方法为什么解决不好这个问题。然后思考你的工作有没有这些问题，要不要上 restful 解决这些问题。

[Ouyangan]

我也一直在迷惑这个, 那么下面这种方式如何呢?

user/insert
user/select
user/update
user/delete
user/list

[zoffy]

就像 MVC 一样，是 software engineering 里的一种思想

[edison111cry]

@akinoniku
多谢回复，但是看到楼下的回复说好像又不太像是一回事了

[edison111cry]

@Kilerd
这个 index.php 只是示意一下。
但是您写的 POST http://www.test.com/comment {"uid": 1234, "content": "good"}
我还不是太能理解。
因为我用的 THINKPHP 框架，所以 Comment 这个对应的是类， addComment 对应的是方法，如果要把这条 API 链接发给 APP 人员，让他们写在程序里调用的话，不应该还是要用
http://www.test.com/index.php/Comment/addComment/uid/1234/content/good
这程格式吗？

[ytmsdy]

@Kilerd
POST http://www.test.com/comment {"uid": 1234, "content": "good"}
最后没要注意加 / 哦。。。要不然会报错的。。哈哈哈

[sparkle2015]

@Kilerd @edison111cry
其实更正确一点，应该是这样：
POST http://www.test.com/comments {"content":"good"}
comments 应该用复数，而 uid 我认为并不需要，因为，只有登录用户才可以评论，而登录用户的信息比如 token 应该放在每一个请求的 header 里。

[yongzhong]

可以参考谷歌的 API 设计指南 https://cloud.google.com/apis/design/

[edison111cry]

@baiyi
多谢哈，刚刚粗略看完了，不过依然还是比较晕。
如果能有更直接更简单的，比如就直接依照我用的例子里：
http://www.test.com/index.php/Comment/addComment/uid/1234/content/good
这种 THINKPHP 里给出一个例子，可能我就能豁然开朗了。哈哈

[ltux]

RESTful 是一种网站交互接口设计风格，并无官方标准，简单说它的要求就两条： 1 ，所有对资源操作的方式都用标准 http method 指定，比如 增删查改 分别对应 post 、 delete 、 get 、 put ，相应地，操作成功与否的信息也应该用标准的 http 响应码来表示，而非 http response body ； 2 ，所有的作用域信息都用 URI 指定。

你用 get http://www.test.com/index.php/Comment/addComment/uid/1234/content/good 这种方式不是 RESTful ，因为虽然作用域信息是在 URI 里，但是对资源的操作方法 add 也放在 URI 里了， http method 跟真正的操作方法不对应，这种接口风格只能称为 RPC 。

[FinnBai]

@edison111cry #12

唔...这种东西还是需要自己理解吧,直接给例子也不一定能对的上你的项目

我在刚接触 RESTful 的时候查过好多资料,一点点的理解 REST 架构,当然了,到现在也不敢说完全理解

这是我在学习后整理的一片博文.里面的[参考文章]有很多我当初学习是找到的资料,希望能对你有所帮助
http://captainjack.me/2016/12/RESTful%20API%20%E5%AE%9E%E8%B7%B5/

[edison111cry]

@ltux
非常感谢，经您这么一说，我大概明白了我的那个 API 接口不能称之为 RESTFUL API 了。
我用 THINKPHP 来写的，但是怎么把我的这个接口改写成 restful api 还是有点晕。 55555

[yeyuexia]

@Ouyangan
user/insert users POST
user/select users/{id} GET
user/update users/{id} PUT
user/delete users/{id} DLETE
user/list users GET
最基本的东西了 建议先去好好读读 restful 规范吧

[Ouyangan]

@yeyuexia #16 十分感谢哈 , 我明白是利用 http 本身的方法来操作资源,但是我没想明白这样做有什么好处, 解决了什么问题.

[PG6G92lJb7qCYHRt]

传 uid 是不安全的，建议引入用户认证啊

[yeyuexia]

@edison111cry restful 的前提是一个假定：所有的请求都是在处理资源 ，所以 uri 上都应该是名词，而动作则用 http 的 method 在表示 至于 path 的先后顺序 就有些类似面向对象里面设计的类的层级了
添加比如商品的评论
应该是 goods/comments POST user ， content 信息应该传 body 而不应该放在 path 里面

[yeyuexia]

@Ouyangan 其实他作为一个规范的最大好处就是前后端配合熟悉了之后，只需要去看 uri 就能知道是在做什么
对于后端开发来说 还有一个好处就是做 restful 设计的时候 你会更多的考虑你数据结构的设计，让数据结构设计更合理。

[blackjar]

https://mmikowski.github.io/the_lie/

[JerryZhang]

从游戏服务器转到 Web 服务器，用 Django 给 App 提供 API ， 自己琢磨了一下和 App 定了交互规则，用了几个月碰到别人说 RESTFUL ，后来一看和我自己定的规则大同小异。

软件工程中的规则 /模式 /规范，都是为了人与人之间交互使用的，不同的规则会影响协作模式，进而影响效率。所以就有人抽象出来了 RESTFUL 这样的东西，还有设计模式，编码规范等等。

但要知道的是，他们都是辅助，关键还是要看你们团队之间的共识，如果你们一致觉得某个规则是好的，是适合你们的，用就是了。

[fuckgfwfuckgfw]

github.com/txthinking/frank