总是见到文章有提到RESTful API的，却不知道是什么东西，找到这篇文章，觉得讲得不错，就转载到这里来吧。
另外也有一篇文章也不错，发个链接：白话REST-识别真假REST
----------------------
前几日，有一小哥突然问我：陈陈，你会RESTful API吗？我说：不会呀，他说：那我教你好了。然后我就把该小哥拉入“黑名单”了，理由是唱你妹的小星星。然后去深入的学习了一下REST相关的东西。
RESTful API对我并不是一个全新的像是突然蹦出来的词汇，我印象中工作上出现过好几次，但是每次我都没有真正理解这个东西。我不知道什么样的接口类型可以称得上 是一种RESTful API，不知道RESTful API好在哪儿？那么今天这篇文章就是用来解决我的这些困惑的。要声明的是我只会站在前端使用者的角度来说说RESTful API看起来的样子，至于后端如何实现RESTful API接口的事我则不会涉及。
先从Web Service说起。Service就是提供可利用的资源，那么再加上Web这张网就可以对资源利用得到极大延伸，不在局限于你的本地或四邻。这时就应运 而生一种信息交换协议——SOAP（简单对象访问协议，Simple Object Access Protocol）。SOAP有着严格的协议，内容至今也基本齐全，然而随着时间的推进，它的弊端也逐渐暴露出来。SOAP消息基于很老的XML格式，显 得厚重，同时支持多种传输协议如HTTP、TCP/UDP等等，其内容涉及封装以及状态维持等等，总而言之，言而总之，就是它的复杂程度已经违背了起初设 计Web Service的简明原则了，所以在2000年Roy Thomas Fielding提出了REST（Representational State Transfer）架构。算是打响改善的第一枪。如果一个架构符合REST原则，就称它为RESTful架构。
通过对比SOAP和RESTful API的不同点，大致可以让我们了解到RESTful API的样子。
首先SOAP是一种严格的协议，而REST却并非协议，而是一种指导原则。而我个人认为它们最大的不同点在于SOAP是基于事务，而RESTful API是基于资源，然后利用HTTP的方法（GET、POST、PUT、DELETE)来表征行为。
一个SOAP接口可能如下：
GET http://www.example.com/getBook
POST http://www.example.com/addBook
POST http://www.example.com/updateBook
POST http://www.example.com/deleteBook
而对应的RESTful接口可能如下：
GET http://www.example.com/book
POST http://www.example.com/book
PUT http://www.example.com/book
DELETE http://www.example.com/book
以上接口的作用依次为获取书籍、添加书籍、更新书籍、删除书籍，你会发现SOAP提供的接口基本是以动词加名词结尾，是基于做什么事的，而 RESTful风格的接口则是名词结尾，把服务看成资源，然后完全利用HTTP的请求方法来做行为判断。SOAP接口返回XML格式，而RESTful API没有明确应答的格式要求。因为RESTful API只针对HTTP使用设计，所以他能更好的适用于浏览器，以及js的httpRequest请求。
RESTful API轻便的一个原因就是它是无状态的，所以它可以做缓存处理，增进性能，然而这也成为了它的一个短板。其实现在很多Web Service都不是随便可以滥用的，都需要身份验证，权限设置。如果把身份信息放在HTTP head里面，如何保证身份不被伪造？那么在这种情况下RESTful API就无法适用了，反而SOAP可以很好的适应。REST也在不断的完善，也许有一天他也可以做到状态维持，那么是否表明它也成了另一个SOAP呢？所 以没有什么东西是十全十美的，但是却有单一场景下十全十美的东西。
不管怎么说，RESTful API已经流传深远，对SOAP产生了巨大冲击。以上只是个人简单片面的理解，如果要想求真知，还望大家自行查阅资料，涨姿势。