restful api 设计规范

1. 同一种数据的操作，只设置一个url路由，也就是根据请求方法的不同来区分处理逻辑。
可以基于FBV来通过请求方法的不同，处理不同的逻辑，也可以基于CBV来实现。
两种方式CBV更加简洁，不需要判断
2. 域名
为了对用户使用的url和网页中使用的接口api进行区别，
(1)子域名的方式区分，例如：api.baidu.com/v1/login.json
用户一看域名是以api开头的，就知道就接口，返回的是json数据
(2)url的方式进行区分
例如：www.baidu.com/api/v1/login.json
第一种方式需要解决跨域请求的问题，也就是当域名不同或者端口不同的时候，都会出现跨域请求。
第二种，保证了域名和端口的一致性，只是url不一样而已
跨域：因为浏览器的同源策略，当你通过浏览器向www.baidu.com前端页面发送请求的时候，网页需要向后台请求接口，但是如果接口的域名和当前的域名不一致，就会出现跨源请求的错误，无法访问到页面。而跨源是网页向api发送请求之后，服务器响应了这个请求，但是是浏览器端把这一次请求的响应给阻止了，并不是在请求不同域名的接口时，服务端不会响应这个请求。跨源是浏览器端的阻止行为，而不是服务器端的。
3. 版本规则
两个版本共存的时候，应该将api的版本号放入url中。
例如：api.example.com/api/v1/
另一种做法是将版本号放在http头信息中，但不如放入url中方便直观。
4.面向资源编程
将网络中的任何东西都看作是资源，对资源可以进行增删改查的操作，但是资源表示的是一个名称，如果一个url后面跟的是一个名词(单复数都可以)，所用的名词往往与数据库的表格名对应，就表示要对这个资源进行增删改查的操作了。而get/post/delete/put是动词，所以url中不建议出现动词。
例如：www.baidu.com/api/v1/order/ (遵循规范)
www.baidu.com/api/v1/orders/ (遵循规范)
www.baidu.com/api/v1/get_order/ (没有遵循规范)
5. http方法规范
GET：从服务器上获取一个或者多个资源
POST：在服务器上新建一个资源
PUT：在服务器跟新全部资源
PATCH：在服务器更新部分资源
6. 过滤规范
www.baidu.com/api/v1/orders/?status=1&page=2&offset
7. 状态码规范(状态码+code码)
后台提供的状态码，供前端使用。
200系列，300系列表示重定向，400系列表示客户端错误，500系列表示服务端错误(后台代码错误)。
但是只有状态码还是不够的，请求的状态太多，所以除了使用状态码表示状态以外，还应该有code码来表示更加详细的请求情况。
比如：支付宝的code码，20000,20001等

    def get(self,request,*args,**kwargs):
        ret  = {
            'code':1000,
            'msg':'没有携带cookie'
        }
        return HttpResponse(json.dumps(ret),status=201)

8. api 超链接规范
在列表页的json中，restful希望详情页的url也包含在json数据中，就不用单独的进行拼接了