RESTful的post，你是否将对象的单数或复数Uri？
哪一个URI会更适合接收POST（添加产品）？ 有没有最好的做法，或只是个人喜好？
/ product / （单数）
要么
/ products / （复数）
目前，我们使用/products/?query=blahsearch和/product/{productId}/获取单个产品的GETs PUT和DELETE。
由于POST是一个“附加”操作，因此您可能会更加简单地将其发布到/products ，因为您会将新产品附加到现有的产品列表中。
只要你在你的API中标准化了一些东西，我觉得这很好。
由于REST API应该是超文本驱动的，所以URI是相对无关紧要的。 客户端应该从返回的文档中提取URI，并在随后的请求中使用这些URI; 通常应用程序和人们不需要猜测或可视化地解释URI，因为应用程序将明确地指示客户端可用的资源和URI。
通常情况下，如果您事先不知道资源的标识符，则使用POST来创build资源，当您执行时则使用PUT。 所以你会POST到/ products，或者PUT到/ products / {new-id}。
使用这两种方法，您将返回201 Created，并使用POST另外返回包含新创build资源的URL（假定它已成功创build）的Location标题。
您发布或获取一件产品：一个产品。
有时你没有特定的产品（或与查询条件）GET。 但是你仍然用单数来说。
你很less使用复数forms的名字。 如果您有一个产品目录（产品目录），则是一个目录。
在RESTfuldevise中，围绕创build新资源存在一些模式。 您select的模式在很大程度上取决于谁负责为新创build的资源selectURL。
如果客户端负责selectURL，那么客户端应该放置到资源的URL。 相反，如果服务器负责资源的URL，则客户端应该POST到“工厂”资源。 通常情况下，工厂资源是创build资源的父资源，通常是一个多元化的集合。
所以，在你的情况下，我会build议使用/products
我只会发布到单数/product 。 混淆这两个url就太容易混淆或犯错误了。
正如很多人所说，只要你一致，你可以select任何你喜欢的风格，但是我想指出一些双方的观点。 我个人偏向单数
赞成复数资源名称：
- 因为您知道资源名称始终是复数forms的URLscheme的简单
- 许多人认为这个约定与数据库表的处理类似，认为这是一个优点
- 似乎被更广泛地采用
赞成单一的资源名称（这不排除工作在多个资源时的复数）
- urlscheme更为复杂，但您获得更多的performance力
- 你总是知道什么时候你正在处理一个或多个基于资源名称的资源，而不是检查资源是否有一个id查找path参数
- 对非母语人士而言，复数有时更难（当不是简单的“s”时）
- 该URL更长
- 从程序员的angular度来看，“s”似乎是多余的
- 将path参数视为集合的子资源而不是考虑它是什么：只是它标识的资源的ID
你可以为它们使用相同的URL，并使用MessageContext来确定Web服务的调用者想要执行什么types的操作。 没有语言被指定，但在Java中，你可以做这样的事情。
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服务的请求types，并根据请求方法执行相应的操作。
