RESTFUL如何指导WEB API设计？

　　博主刚刚接触web开发的时候，写了一个接口 /get_article_info/1 获取id为1的这篇文章的内容，被前辈们看见了，前辈给我说我这个接口设计的不太好啊，不符合RESTFUL规范，当前辈们说出这些话的时候，我很迷惑，我写的接口不可以好好工做吗？可以正常返回内容啊，对于不存在的文章也可以在返回的内容体中提示不存在，并且接口的意思很明确，一看就能明白，这还有什么很差的地方吗？

1、RESTFUL是什么？

　　RESTFUL是英文单词Representational State Transfer的缩写，翻译成中文就是表现层状态转化，什么是表现层？什么是状态？什么是转化？

　　表现层能够理解为一种资源，能够是一篇文章，一张图片，一个订单...... 全部网络上的一个实体，均可以说是一个资源，在HTTP协议中，URL就是这种资源的表示。状态和转化应当连在一块儿理解，这是一个动做，即状态变化，好比新建一篇文章，状态变化是这篇文章从无到有，还有一些其余状态变化，更新，删除，获取等，那在HTTP协议中如何表示这种变化呢？恰好HTTP协议中有一些请求方法，能够和这些操做对应上，GET表示获取，POST表示新建，DELETE表示删除，PUT表示更新。

　　这样，将HTTP协议的请求方法和URL组合在一块儿，就能表示对哪一个资源进行何种操做，这样的风格就是RESTFUL。

2、 RESTFUL如何指导咱们设计API？

核心思想就是HTTP动词 + URL资源，好比获取文章信息 GET /articles, GET是动词，/articles 是名词

1. 动词一般是HTTP的方法

GET：    获取信息
POST：   新建信息
DELETE： 删除信息
PUT：    更新信息

2. 资源必须是名词

已经有了HTTP的方法的动词，URL中，咱们就没有必要使用动词了

POST /create_articles   
POST /delete_articles   
POST /update_articles   

上面都是很差的用法，咱们应当使用下面这种用法

POST    /articles
DELETE  /articles/2
PUT     /articles/2

3. 资源最好使用名词的复数，任何状况下都可以适用

/airticles/1  获取id为1的文章内容
/airticles    获取全部文章内容

# 使用单数
/article  获取一篇文章内容？仍是全部的文章内容？

4. 避免多级URL

/authors/5/airticles  获取做者id为5的全部文章

上面换成这种形式更好，也利于扩展
/airticles?author_id=5

5. 利用querystring来过滤和筛选

通常状况下一个url很难知足复杂多变的状况，好比分页，过滤，这时候咱们应当如何设计？

/airticles/published  这种形式？

不不不，published不是一个资源，并且这种url不宜于扩展

最佳实践应当是下面这种形式

/articles?page=1          获取第一页的文章
/articles?published=true  获取已经发布的文章

6. 返回有意义的状态码

HTTP有不少状态码，表示不一样的意义，咱们应当充分利用这些状态码

尤为是出现错误时，不要返回200，意义很不明确

通常成功请求后返回的状态码

GET：200 OK
POST：201 Created
PUT：200 OK
DELETE：204 No Content

其余状态码信息

1xx：相关信息

2xx：请求成功

3xx：重定向

4xx：客户端错误

5xx：服务器端错误

2xx状态码表示成功

200 OK 请求成功

201 Created 请求成功，并建立了资源

202 Accepted 请求接受，但未处理完成，通常用于异步处理

204 No Content 请求处理成功，但未返回内容，通常用于DELETE请求成功

3xx状态码表示重定向

301 Moved Permanently 永久重定向

302 Found 暂时重定向

4xx状态码表示客户端错误

400 Bad Request 错误请求，服务器不理解请求，没作任何处理

401 Unauthorized 未认证

403 Forbidden 用户经过了认证，可是没有权限

404 Not Found 没有发现请求的内容

405 Method Not Allowed 不容许的请求方法

5xx状态码表示服务端错误

500 Internal Server Error 服务器内部错误，没法完成请求

503 Service Unavailable 服务不可用

3、总结

　　RESTFUL就是一种规范，咱们不遵循这种规范也可以写出可用的代码，可是遵循这种规范却能给咱们带来更多的好处，API设计更加可读，与其余人交流也可以很方便。如今让我看看我刚刚接触web接口开发时的设计，真的是不太好啊，URL信息过重复，错误的返回状态不明确，全是200。

参考文章：https://blog.florimond.dev/restful-api-design-13-best-practices-to-make-your-users-happy