其他RESTful API心得

调用api时要有http的前缀，否则出错Error Domain

关于其他（比如移动）端去调用REST的api时，要注意一点的是：

记得url地址写全了，最前面要加上http或https的前缀， 比如：

http://115.29.173.126:21084/runningfast/api/v1.0/open/smscode

否则，如果漏了，变成：

115.29.173.126:21084/runningfast/api/v1.0/open/smscode

就会报错：

FAILURE: Error Domain=NSURLErrorDomain Code=-1002 unsupported URL或URL not supported

详见：【已解决】iOS端用Alamofire访问Flask的rest的api出错：Error Domain=NSURLErrorDomain Code=-1002

api中是否一定要加版本号？

如果是为了设计长期稳定的API接口，则最好是加上版本号v1.0这种写法 http://[hostname]/todo/api/v1.0/ 但是往往中小型项目不需要这么长期维护和不需要迭代太多版本，则可以考虑不需要版本号，则可以写成： http://[hostname]/todo/api/ 即可。

另外了解到： 有些的做法是把API的版本号v1，放到request header中。 ->github就是这么做的：Media Types | GitHub Developer Guide

设计Restful的接口时，尽量用复数，且统一

即，用/artists而不要用/artist

如果有多个对象，用模块化逻辑，嵌套资源去设计接口

举例：

获取某个（内部id为8的）歌手的所有的专辑： GET /artists/8/albums

是否一定要严格按照Restful的规则，用对应的http的method实现对应的功能？

一般来说，不用非常严格的依照规则，尤其是

  • UPDATE/PATCH 去更新修改资源
    • 往往为了简化，用PUT表示 更新修改资源即可

不过，有些项目，对方本身就要求设计接口时，严格按照Restful的规则来设计，这时最好用UPDATE/PATCH去更新修改资源。

其他的，见上面的表格总结，典型的是：

  • GET 获取资源
  • POST 新建资源
  • PUT 更新/修改 资源
  • DELETE 删除资源

POST时body中无参数时不应该添加Content-Type:application/json的Header

比如POST时,如果没有Body内容参数传递时，Header中就不要包含 Content-Type:application/json

否则，某些服务器就会返回错误。

比如Flask的Flask-Restful的接口就会自动返回：

code = 0 message = Failed to decode JSON object: No JSON object could be decoded

-》其意思是，你指定了

Content-Type:application/json

所以框架就会去尝试从Body中找JSON字符串，去解析参数

但是发现Body是空的，没有可用的JSON字符串待解析，所以报这个错误。

results matching ""

    No results matching ""