第一:

我认为有两种方法

http://our.api.com/Product/<id>:如果你只想要一条记录

http://our.api.com/Product:如果你想要所有的记录

http://our.api.com/Product/<id1>，<id2>:正如James建议的那样，可以作为一个选项，因为Product标记后面的内容是一个参数

或者我最喜欢的是:

您可以使用RestFul WS的Hypermedia作为应用程序状态的引擎(HATEOAS)属性，并调用http://our.api.com/Product，该调用应该返回http://our.api.com/Product/<id>的等效url，并在此之后调用它们。

第二个

当你必须对url调用进行查询时。我建议再次使用HATEOAS。

1)给http://our.api.com/term/pumas/productType/clothing/color/black打个get电话

2)给http://our.api.com/term/pumas/productType/clothing,bags/color/black,red打个get电话

3)(使用HATEOAS)做一个得到调用' http://our.api.com/term/pumas/productType/ ->接收url所有服装可能的url ->调用那些你想要的(服装和包)->接收可能的颜色url ->调用那些你想要的

第一个例子:

一个正常的乘积查找应该是这样的

http://our.api.com/product/1

所以我认为最好的做法是由你来做这件事

http://our.api.com/Product/101404,7267261

第二个案例

使用查询字符串参数进行搜索-就像这样。我会倾向于用AND和OR来组合术语，而不是使用[]。

附:这可能是主观的，所以做你觉得舒服的事情。

将数据放在url中的原因是链接可以粘贴到站点上/在用户之间共享。如果这不是一个问题，无论如何使用JSON/ POST代替。

编辑:经过反思，我认为这种方法适合具有复合键的实体，但不适用于多个实体的查询。

后退一步

首先，REST将URI描述为通用唯一ID。太多的人纠结于uri的结构以及哪些uri比其他uri更“rest化”。这个论点就像说给一个人起名叫“Bob”比给他起名叫“Joe”更好一样可笑——这两个名字都能完成“识别一个人”的工作。URI只不过是一个普遍唯一的名称。

因此，在REST的眼中，争论?id=["101404"，"7267261"]是否比?id=101404,7267261或\Product\101404,7267261更安静，多少有些徒劳。

话虽如此，很多时候，uri的构造方式通常可以作为rest式服务中其他问题的良好指示器。在您的uri和问题中有一些危险信号。

建议

Multiple URIs for the same resource and Content-Location We may want to accept both styles but does that flexibility actually cause more confusion and head aches (maintainability, documentation, etc.)? URIs identify resources. Each resource should have one canonical URI. This does not mean that you can't have two URIs point to the same resource but there are well defined ways to go about doing it. If you do decide to use both the JSON and list based formats (or any other format) you need to decide which of these formats is the main canonical URI. All responses to other URIs that point to the same "resource" should include the Content-Location header. Sticking with the name analogy, having multiple URIs is like having nicknames for people. It is perfectly acceptable and often times quite handy, however if I'm using a nickname I still probably want to know their full name – the "official" way to refer to that person. This way when someone mentions someone by their full name, "Nichloas Telsa", I know they are talking about the same person I refer to as "Nick". "Search" in your URI A more complex case is when we want to offer more complex inputs. For example, if we want to allow multiple filters on search... A general rule of thumb of mine is, if your URI contains a verb, it may be an indication that something is off. URI's identify a resource, however they should not indicate what we're doing to that resource. That's the job of HTTP or in restful terms, our "uniform interface". To beat the name analogy dead, using a verb in a URI is like changing someone's name when you want to interact with them. If I'm interacting with Bob, Bob's name doesn't become "BobHi" when I want to say Hi to him. Similarly, when we want to "search" Products, our URI structure shouldn't change from "/Product/..." to "/Search/...".

回答你最初的问题

Regarding ["101404","7267261"] vs 101404,7267261: My suggestion here is to avoid the JSON syntax for simplicity's sake (i.e. don't require your users do URL encoding when you don't really have to). It will make your API a tad more usable. Better yet, as others have recommended, go with the standard application/x-www-form-urlencoded format as it will probably be most familiar to your end users (e.g. ?id[]=101404&id[]=7267261). It may not be "pretty", but Pretty URIs does not necessary mean Usable URIs. However, to reiterate my initial point though, ultimately when speaking about REST, it doesn't matter. Don't dwell too heavily on it. Your complex search URI example can be solved in very much the same way as your product example. I would recommend going the application/x-www-form-urlencoded format again as it is already a standard that many are familiar with. Also, I would recommend merging the two.

你的URI ...

/Search?term=pumas&filters={"productType":["Clothing","Bags"],"color":["Black","Red"]}    

你的URI被URI编码后…

/Search?term=pumas&filters=%7B%22productType%22%3A%5B%22Clothing%22%2C%22Bags%22%5D%2C%22color%22%3A%5B%22Black%22%2C%22Red%22%5D%7D

可以转化为……

/Product?term=pumas&productType[]=Clothing&productType[]=Bags&color[]=Black&color[]=Red

除了避免对URL编码的要求并使事情看起来更标准之外，它现在还使API更加同质化了。用户知道，如果他们想检索一个Product或List of Products(两者在RESTful术语中都被视为单个“资源”)，他们对/Product/…uri。

将值列表作为URL参数传递的标准方法是重复它们:

http://our.api.com/Product?id=101404&id=7267261

大多数服务器代码将其解释为一个值列表，尽管许多服务器有单个值的简化，因此您可能需要查看。

带分隔符的值也可以。

如果你需要向服务器发送JSON，我不喜欢在URL中看到它(这是一种不同的格式)。具体来说，url有大小限制(理论上没有限制，但实际上是这样)。

我见过一些人用rest完成复杂查询的方法分为两步:

POST您的查询需求，接收回一个ID(本质上是创建一个搜索条件资源) 获取搜索，引用上面的ID 如果需要，可以选择删除查询需求，但是注意这些需求是可重用的。

您可能需要查看RFC 6570。这个URI模板规范展示了url如何包含参数的许多示例。

我会支持nategood的回答，因为它是完整的，它似乎满足了你的需要。尽管如此，我还是想补充一个关于以这种方式识别多个(1个或更多)资源的评论:

http://our.api.com/Product/101404,7267261

在这样做时，你:

使客户端复杂化 迫使他们将你的响应解释为一个数组，如果我提出以下请求:http://our.api.com/Product/101404，这对我来说是违反直觉的

创建冗余api 用一个API获取所有产品，上面的API获取1个或多个产品。因为出于用户体验的考虑，你不应该向用户显示超过1页的详细信息，我认为超过1个ID是没有用的，纯粹是用来过滤产品的。

这可能不是什么问题，但是您要么必须自己在服务器端通过返回单个实体(通过验证您的响应是否包含一个或多个实体)来处理这个问题，要么让客户端管理它。

例子

我想从《神奇》订购一本书。我确切地知道这是哪本书，当我导航恐怖书籍时，我在列表中看到它:

10000条惊人的线，0个惊人的测试 神奇怪物的回归 让我们复制令人惊叹的代码 结局的惊人开端

在选择第二本书后，我被重定向到一个详细介绍列表中书籍部分的页面:

--------------------------------------------
Book #1
--------------------------------------------
    Title: The return of the amazing monster
    Summary:
    Pages:
    Publisher:
--------------------------------------------

还是在一页里只给我这本书的全部细节?

---------------------------------
The return of the amazing monster
---------------------------------
Summary:
Pages:
Publisher:
---------------------------------

我的意见

我建议在获取该资源的详细信息时，当保证惟一性时，在路径变量中使用ID。例如，下面的api提供了获取特定资源详细信息的多种方法(假设产品有唯一的ID，该产品的规范有唯一的名称，并且您可以自顶向下导航):

/products/{id}
/products/{id}/specs/{name}

当您需要多个资源时，我建议从更大的集合中筛选。同样的例子:

/products?ids=

当然，这是我的意见，因为它不是强加的。