在前后端分离的今天，前端除了需要完成复原设计稿的任务外，还有个重要的工作，就是和后端对接好RESTful API，以将数据和UI进行绑定，从而实现UI的动态展示。RESTful API对前端而言，只是一个由XHR或fetch请求后返回的JSON数据，随后对这段JSON数据进行处理，那么对后端而言需要做的就多了，除了搭建基本后台框架，还要编写服务代码，那么如何写出一个好用且赏心悦目的RESTful呢，那就得先了解前后端在对接RESTful API时遇到的痛点。
为什么这个接口那么难用
“为什么这个接口那么难用”，当前端或其他服务调用不符合规范的RESTful API时，经常会发出类似的抱怨，出现这个问题的原因有以下几点：
命名不规范
命名不规范的场景有很多，从我工作中发现有以下情况：
- 大量使用拼音，拼音缩写
- 返回字段直接使用数据库字段，名字不仅长而且全部使用大写
- 使用无意义的命名
这几种情况在团队合作中都是非常不友好的做法，也会给后期的维护带来极大的困扰，合理的API写法应该遵循以下规则：
- 使用资源层级划分，使用“/”做为分隔符，对应后台的文件层级，便于后期维护，如
/shapes/polygons/quadrilaterals/squares - 使用英文命名，杜绝使用拼音和拼音缩写
- 不要使用大写
- 名字使用
-连接符，不要使用驼峰式或下划线_ - 返回的参数要进行encode，避免因为出现乱码导致的前台应用奔溃
清一色的使用POST
不管何种情况，所有的请求都使用POST请求，这也是常见的不规范情况之一。清一色使用POST虽然也可以能完成任务，但如果要符合命名规范的话，就得把每一个URI的作用都写在uri上，比如同样是对用户数据表的CRUD操作，就会有/user/add-user,/user/update-user,/user/delete-user,/user/find-user四个不同的URI，这也增加了后台路由的复杂度，其实标准的HTTP提供了5种方法表示RESTful API的操作：GET, POST, PUT, DELETE,HEAD/OPTION，大家一定要对这几个操作方法加以善用，让API和功能达成一致。
没有错误处理
很多时候，API体验不好的表现就是后台异常没有处理，例如触发后台异常，直接将错误堆栈信息一股脑全返回，导致前端或其他服务直接奔溃，从而造成一系列的连锁反应。 合格的RESTful API开发会预判自身可能触发的错误，并在容易出错的地方进行try-catch处理，适时将错误结果返回给客户端。
善用状态码
没有合理使用状态码也是API使用体验不佳的其中一个原因。不少RESTful开发者不明确各种状态码的作用是什么，也只是记住了200这种成功状态码，便在所有的API中都使用200状态码，更有甚者直接不使用状态码，这种也是对客户端不负责的表现，试想如果不使用状态码，客户端如何判断本次请求返回结果是做成功处理，还是异常处理？
合理的做法是合理使用状态码，成功状态200，权限相关使用4xx，服务器异常使用5xx，更多状态码语义可以直接使用搜索引擎。
总结
以上是本人在工作中亲身体会并总结的RESTful API在使用过程中遇到的问题以及改善建议，另付一个自己总结的RESTful API的开发规范导图，希望各位也能写出能让自己和客户端都愉悦的API。
