一、现状：

前天与后端开发人员讨论了API接口的设计。有以下三种方案：

1、原始HTTTP协议
HTTP状态码就是该Request的状态码，不应该与后端业务混在一起（这也是一部分人使用该方案的理由）。比如200表示该Request成功了，具体业务有没有操作成功还需要在response body里再标记，比如1表示操作成功，0表示操作失败。
2、HTTP协议 RESTful 风格
充分利用HTTP状态码，比如200就是该操作成功，定义一个5xx表示业务操作失败，如果该业务失败有多种情况则在response body里再标记。
3、SOAP

三者都可以实现，当然是推荐使用2，现在各大网络框架和大的开发平台API 基本都是这样的。

二、RESTful 中http code 设计

1、标准的200的含义
请求已成功，请求所希望的响应头或数据体将随此响应返回。这句话的意思不就是业务操作成功嘛。
2、RESTful 对200 多了一条要求：幂等性
幂等的意思是请求成功执行所得到的的结果不依赖于该方法被执行的次数。也就是说如果HTTP状态码是200，那么reponse body的报文结构应该只有一种。

三、RESTful 优点

1．面向资源的接口设计
所有的接口设计都是针对资源来设计的，也就很类似于我们的面向对象和面向过程的设计区别，只不过现在将网络上的操作实体都作为资源来看待，同时URI的设计也是体现了对于资源的定位设计。这样更符合自然语义。简化了开发者的不良设计。例如DELETE /zoos/ID：删除某个动物园 200 就是删除成功，非200就是删除失败。符合自然语义。使得客户端的处理逻辑变得简单。
2．抽象操作为基础的CRUD

这点很简单，Http中的get,put,post,delete分别对应了read,update,create,delete四种操作，最大限度的利用了Http最初的应用协议设计理念。
3．Http是应用协议而非传输协议
SOAP协议对于消息体和消息头都有定义，消息头的可扩展性高，但是也由于SOAP由于各种需求不断扩充其本身协议的内容，导致在SOAP处理方面的性能有所下降。同时在易用性方面以及学习成本上也有所增加。 SOAP 把HTTP当做传输层来使用了，自己封装了一套应用协议。而RESTful 本身不是协议，是一种HTTP协议的使用规范，使得HTTP协议就是作为应用层来使用。简洁易用。

四、RESTful vs JSON-RPC

JSON-RPC是一个无状态且轻量级的远程过程调用(RPC)协议。本规范主要定义了一些数据结构及其相关的处理规则。它允许运行在基于socket,http等诸多不同消息传输环境的同一进程中。其使用JSON（RFC 4627）作为数据格式。

Web Service 也提出了好久了, 那么究竟什么是 Web Service ?

简单地说, 也就是服务器如何向客户端提供服务.

常用的方法有:

RPC 所谓的远程过程调用 (面向方法)
SOA 所谓的面向服务的架构(面向消息)
REST 所谓的 Representational state transfer (面向资源)

JSON-RPC协议描述

json-rpc协议非常简单，发起远程调用时向服务端传输数据格式如下：

{ “method”: “sayHello”, “params”: [“Hello JSON-RPC”], “id”: 1}

参数说明：

method：调用的方法名

params：方法传入的参数，若无参数则传入 []

id ：调用标识符，用于标示一次远程调用过程

服务器其收到调用请求，处理方法调用，将方法效用结果效应给调用方；返回数据格式：

{
“result”: “Hello JSON-RPC”,
“error”: null,
“id”: 1
}

http://wiki.geekdream.com/Specification/json-rpc_2.0.html
http://gubaojian.blog.163.com/blog/static/1661799082012101439591/
http://www.cnblogs.com/mindsbook/archive/2009/11/17/web_service_RESTvsRPC.html

API的HTTP状态码设计相关推荐

SpringCloud工作笔记048---RESTful API 中 HTTP 状态码的定义_以及把RESTFul版本号_放到http协议header中_以及RestFul设计时的两个误区
JAVA技术交流QQ群:170933152 ------------------------- RESTful架构有一些典型的设计误区. 最常见的一种设计错误,就是URI包含动词.因为"资源 ...
php返回200,关于API 使用 HTTP 状态码还是全部返回 200
现在的项目api想用restful风格,然后目前的api接口返回规范:所有成功接口返回{status:200,msg:'',data:{}},出错接口返回{status:403,msg:'',data ...
关于 RESTful API HTTP状态码
关于 RESTful API 中 HTTP 状态码的定义其中 2XX/3XX 其实都是请求成功,但是结果不同.4XX 是请求出错,5XX 是服务器处理出现错误. 200 这个最容易理解,就是正确的请 ...
symfony api 错误响应_如何设计一个牛逼的 API 接口
在日常开发中,总会接触到各种接口.前后端数据传输接口,第三方业务平台接口.一个平台的前后端数据传输接口一般都会在内网环境下通信,而且会使用安全框架,所以安全性可以得到很好的保护.这篇文章重点讨论一下提 ...
关于Restful API与状态码的设计
一.API 1. 传输协议采用HTTP JSON通讯协议 2. API版本控制将API得版本号放入URL,http://api.example.com/v{n}/ v{n} n代表版本号,使用整形 ...
趣说API HTTP 状态码的使用
在设计API HTTP 状态码的时候,我们总能听到两种声音: 第一种,也是大家最常用的: 所有接口的状态码都返回 200,然后在自定义错误码: # 正确响应 {"code: 200,&quo ...
【Servlet】什么是Servlet；常见状态码；Servlet API；Cookie和Session
Servlet 文章目录 Servlet 1. Servlet是什么 2. 第一个Servlet程序 2.1 创建项目 2.2 引入依赖 2.3 创建目录 2.4 编写代码 2.5 打包程序 2.6 ...
使用ASP.NET Core 3.x 构建 RESTful API - 3.3.1 HTTP状态码
HTTP状态码会告诉API的消费者以下事情: 请求是否执行成功了如果请求失败了,那么谁为它负责 HTTP的状态码有很多,但是Web API不一定需要支持所有的状态码.HTTP状态码一共分为5个级别: ...
接口API封装中常见的HTTP状态码
在进行后端接口API封装的过程中,需要考虑各种错误信息的输出.一般情况下,根据相应问题输出适合的HTTP状态码,可以方便前端快速定位错误,减少沟通成本. HTTP状态码有很多,每个都有对应的含义,下面 ...

API的HTTP状态码设计

一、现状：

二、RESTful 中http code 设计

三、RESTful 优点

四、RESTful vs JSON-RPC

API的HTTP状态码设计相关推荐

最新文章

热门文章