REST服务应该使用输入内容类型进行响应吗?

时间:2012-02-14 14:51:41

标签: web-services rest

如果使用JSON,我们返回JSON。如果使用XML,我们返回XML。对于我们接受表格编码数据(“application / x-www-form-urlencoded”)的请求,返回表格编码数据是否可以接受?

另外,在出现错误的情况下,大多数实现会做什么?我看到主题有很多不同的变化。

2 个答案:

答案 0 :(得分:3)

不,没有理由。

但客户端可以使用Accept:标头请求特定格式。如果服务器不支持该格式,则应返回406 Not Acceptable。如果根本没有Accept:标头,或者客户端使用*作为后备,服务器可以选择默认值。

答案 1 :(得分:2)

返回表单编码数据虽然不是一种糟糕的方法,但却是我从未见过的。我认为,最好坚持使用更常见的格式。当请求没有指定时,大多数API会选择要发送的默认格式(通常是XML或JSON)。

对于错误,REST的主要原则是使用HTTP已经提供的方法,因此首先返回相应的错误状态代码(在400s and 500s中)以及响应正文中的错误消息。

错误响应正文没有标准格式 - 它可能很简单:

{ "error" : "Invalid articled ID" }

..或更多涉及,如Flickr的:

{ "stat"    : "fail",
  "code"    : "97",
  "message" : "Missing signature"
}

..及其XML等价物:

<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
  <err code="97" msg="Missing signature" />
</rsp>

显然,使用您的API的开发人员会欣赏更详细的错误消息。主要是我认为您应该在API中寻求一致性 - 如果您在一个地方有一个名为Message的参数,则在另一个地方没有一个名为message的参数。

顺便说一下,我已经处理了一个实际的第三方制作API,它不仅制作了上面的 faux pas ,而且还将结果作为管道(|)分隔的数据包含在XML。值中的文字管道被另一个管道(||)转义。我将把你发现的进一步复杂化留给你的想象力。无论如何,道德是使用开发人员已经习惯的结构和技术,而不是在你做出的选择中保持一致

相关问题