我正在设计一个REST API，并为“people”提供了一个实体：
GET http://localhost/api/people
返回系统中所有人的列表
GET http://localhost/api/people/1
返回身份1的人。
GET http://localhost/api/people?forename=john&surname=smith
返回所有具有匹配的姓氏和姓氏的人，但我还有其他要求。允许API使用者检索其名字以“jo”开头的所有人的最简洁/最佳实践方法是什么。
我见过一些API就像这样：
GET http://localhost/api/people?forename=jo~&surname=smith
波形符号表示“模糊”匹配。另一方面，我看到它以完全不同的标准实施，例如
GET http://localhost/api/people?forename-startswith=jo&surname=smith
任何人都可以根据经验更好地提出建议，也可以提供具有类似功能的精心设计的REST API的任何示例。
答案 0 :(得分：4)
恕我直言，如果你有模糊匹配或者有-endswith -contains等没关系。重要的是你的REST API是否允许轻松解析这些参数，以便你可以定义从数据源获取数据的函数（DB或xml文件等）相应地
如果您使用的是PHP ...根据我的经验，SlimFramework是一个非常轻量级，易于上手的解决方案。
答案 1 :(得分：3)
我会向你推荐提供OData protocol的Query String Options。您所做的就是确定并遵循REST约定。
但是，OData协议描述了$expand参数甚至是$filter参数。此$前缀表示“系统查询选项”，您将对最后一个感兴趣，因为它允许您编写以下URI：
http://services.odata.org/Northwind/Northwind.svc/Customers?$filter=tolower(CompanyName) eq 'foobar' &select=FirstName,LastName&$orderby=Name desc
它允许您像数据一样传递SQL，它可以是您所描述的一个很好的替代方案（两种解决方案都很好，这只是一个品味问题）。
答案 2 :(得分：1)
AFAIK，以上都不是RESTful。它们都依赖于客户端关于如何调用查询的修道院知识（在第一种情况下，查询模式，在第二种情况下，查询DSL）。实际上，在第二个示例中，API仅仅被简化为数据存储的包装器。因此，API不定义服务器域 - 它是数据提供者。这与REST的客户端 - 服务器约束形成对比。
如果您需要公开具有各种查询功能的完整数据存储，您最好坚持使用 OData 的已知标准。 OData已作为REST出售，但许多REST头有问题。无论如何，在一天结束时它的工作和REST讨论通常会导致分析瘫痪。
如果我这样做，我可能会将API限制为一个常见的用例，所以更像是第二个没有定义查询DSL的东西（因此forenameStartsWith而不是forename-startswith）。
话虽如此，如果您需要根据许多字段和各种条件进行查询，我会使用OData。
答案 3 :(得分：0)
这两个示例都使用查询参数进行过滤。我认为调用这些查询参数或使用某些通配符语法并不重要。
两种方法都是RESTFul。