restful posts,您将对象发布到单数或复数URI吗?

因为post是一个“append”操作,所以 可以 更英格兰人的职位 /products ,因为您将在现有产品列表中添加新产品。

只要你已经标准化了你的API中的一些东西,我认为这已经足够好了。

由于RESTAPI应该是超文本驱动的,因此无论如何,URI都是相对不合理的。客户机应该从返回的文档中提取URI,并在随后的请求中使用它们;通常应用程序和人员不需要猜测或直观地解释URI,因为应用程序将明确地指示客户机哪些资源和URI可用。

通常,当您事先不知道资源的标识符时,使用post创建资源,并在创建时放置。所以你可以发布到/products,或者发布到/products/new id。

使用这两种方法,您将返回201 created,并使用post另外返回包含新创建资源的URL的位置头(假设已成功创建)。

你发布或得到一件事:一件产品。

有时,您没有特定的产品(或查询条件)。但你还是用单数来表达。

你很少使用复数形式的名字。如果您有一个集合(产品目录),它就是一个目录。

在RESTful设计中,围绕创建新资源有一些模式。您选择的模式很大程度上取决于谁负责为新创建的资源选择URL。

如果客户机负责选择URL,那么客户机应该将其放到资源的URL上。相反,如果服务器负责资源的URL,那么客户机应该发布到“工厂”资源。通常,工厂资源是正在创建的资源的父资源,通常是一个多元化的集合。

因此,在您的情况下,我建议使用 /products

我只会发到单数 /product . 把这两个URL-S混在一起太容易了,很容易混淆或者出错。

正如许多人所说,只要你始终如一,你可以选择任何你喜欢的风格,但是我想指出双方的一些论点;我个人倾向于单一风格

支持复数资源名称:

• URL方案的简单性,如您所知,资源名称始终为复数。
• 许多人认为这种约定类似于数据库表的寻址方式,并认为这是一种优势。
• 似乎被广泛采用

支持单一资源名称(在处理多个资源时不排除复数)

• URL方案更复杂,但您获得的表现力更高
• 当您根据资源名称处理一个或多个资源时,您总是知道,而不是检查资源是否具有以下ID查找路径参数
• 对于非母语人士来说,复数有时更难(当不是简单的“s”时)
• URL较长
• 从程序员的角度来看,“s”似乎是多余的。
• 将path参数视为集合的子资源,而不是将其视为集合的子资源,这很尴尬:只是它标识的资源的ID

您可以对所有这些应用程序使用相同的URL,并使用messagecontext来确定Web服务调用者要执行的操作类型。 没有语言被指定,但是在爪哇你可以做这样的事情。

WebServiceContext ws_ctx;
MessageContext ctx = ws_ctx.getMessageContext();
String action = (String)ctx.get(MessageContext.HTTP_REQUEST_METHOD);
if(action.equals("GET")
  // do something
else if(action.equals("POST")
  // do something

这样,您就可以检查发送到Web服务的请求的类型,并根据请求方法执行适当的操作。