公共API设计-使用http代码处理失败?那是休息吗?

像Flickr和Twitter这样的大型提供商已经把REST的定义搞得一团糟。许多开发人员现在错误地认为HTTP上的任何服务或API都是“RESTful”的。真正的restfulapi使用流畅的HTTP和Web标准,并且以资源为中心。

例如,用于用户查找的RPC服务在成功时可能返回以下内容:

SUCCESS=1
USERNAME=example
FIRSTNAME=Example
LASTNAME=User
DISPLAYNAME=Example User

同一服务在出现故障时可能会返回以下内容:

SUCCESS=0
ERRORCODE=1002
ERRORMSG=User subsystem error; requested user was not found.

在RPC服务中,响应的确切细节非常灵活。它所做的只是将方法调用的结果传递给调用程序。只要您记录了开发人员应该看到的内容,并返回清晰一致的消息,就可以很好地解决问题。RPC服务应该返回的HTTP状态码只有200和500(只有在情况严重时,甚至不能返回正确的错误)。

中的可用用户帐户数

GET/api/users/example-应返回 如果用户 不存在。

帐户;应返回 新建帐户(方法) 这会有所不同,但位置标头 可能会返回代码,具体取决于 结果。

PUT/api/users/example-编辑 各种HTTP状态码可能是

DELETE/api/users/example-删除 现有用户帐户。各种HTTP

RESTful接口最常见的标准HTTP状态代码如下。

• -已完成创建新资源的请求,并且未返回包含新资源表示形式的响应正文。还应返回包含新创建资源的规范URI的位置头。
• 202接受 -已接受请求进行处理,但处理尚未完成。根据HTTP/1.1规范,返回的实体(如果有的话)应该包括请求当前状态的指示,以及指向状态监视器的指针,或者用户可以期望请求何时完成的一些估计。
• -服务器已完成请求,但不需要返回响应消息正文。
• 400错误请求 -无法处理该请求,因为它包含丢失或无效的信息(例如输入字段上的验证错误、缺少必需的值等)。
• 403禁止 -服务器已识别您的凭据,但您没有执行此请求的权限。
• 404未找到 -请求指定了不存在的资源的URI。
• 405方法不允许 -此请求URI不支持请求中指定的HTTP谓词(DELETE、GET、HEAD、POST、PUT)。
• -此请求标识的资源无法生成与请求的Accept标头中的某个媒体类型对应的表示。
• 409冲突 -无法完成创建或更新请求,因为这将导致服务器支持的资源的当前状态发生冲突(例如,尝试创建一个新资源,并且已将唯一标识符分配给某个现有资源)。
• 500内部服务器错误 -服务器遇到意外情况,无法完成请求。
• 501未实施 -服务器(当前)不支持满足请求所需的功能。
• -由于服务器临时过载或维护,服务器当前无法处理该请求。

希望这些信息是有用的,而不是过载。:-)