REST

现在对开发者要求有分布式的经验，而其中 REST 是分布式系统的一种常见架构模式/风格。通过复用HTTP的基本操作，如 GET，POST，PUT还有DELETE

REST 的核心就是通过提供一个共享词汇，以一种标准的，可预测的格式传输资源，下面我们基于 REST 的用于管理用户数据的 JSON 服务

• URL 只是表达被操作的资源位置，因此不应该使用动词，注意单复数区分
• 除了 POST 和 DELETE 之外，其他的操作需要幂等的，例如对数据多次更新应该返回同样的内容
• 设计风格没有对错之分，RESTful 一种设计风格，与此对应的还有 RPC 甚至自定义的风格 RESTful 和语言、传输格式无关
• 无状态，HTTP 设计本来就是没有状态的，之所以看起来有状态因为我们浏览器使用了 Cookies，每次请求都会把 Session ID（可以看做身份标识）传递到 Headers 中
• RESTful 没有定义 Body 中内容传输的格式，有另外的规范来描述怎么设计 Body 的数据结构

GET

得到资源(可以在第一次请求后，缓存资源) - 获取用户信息

• rest.com/users

payLoad: 
    none
Response:[
    {
        "id":123,
        "name":"fong"
    },
    {
       "id":124,
        "name":"lua"
    }
]

• rest.com/users/123

payLoad: 
    none
Response:{
        "id":123,
        "name":"fong"
    }

• rest.com/users?name=… 支持模糊查询

payLoad: 
    none
Response:[
    { 
        "id":124,
        "name":"lua"
    }
]

PUT

更新资源(如果更新缓存资源，要保证下次的不是脏数据) - 修改用户信息

• rest.com/users

payLoad:[
    {
        "id":123,
        "name":"fong1"
    },
    {
       "id":124,
        "name":"lucas"
    }
]
Response:
    200 OK

POST

创建新资源 - 创建用户

• rest.com/users

payLoad:
    {
        "name":"dev" // id自增长，所以不传id
    }
Response:
    200 OK

DELETE

删除资源 - 删除用户

• rest.com/users 删除所有用户

payLoad: None
Response:
    200 OK

• rest.com/users/123 删除id为123的用户

payLoad:None
Response:
    200 OK

• rest.com/users?name=… 删除所有名为lua的用户

payLoad:Null
Response:
    200 OK

下面举几个反例:

• rest.com/users/getus…
• rest.com/users/updat…
• rest.com/users/delet…