GET https://api.website.com/v1/project/employee;company-id={company-id},
title={title-id}?non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3>
其中：company-id 是必需的，title 是可选的 name/value 可以是任何过滤条件。
有没有更好的方法来定义接口？
此 API 不应创建员工对象。它用于获取属于特定公司并具有特定标题和其他过滤条件的员工对象数组。
这个 api 应该获取满足属于特定公司的给定标准的员工对象，具有特定的职位和一些其他过滤条件。
就我个人而言，我只会将您的 URI 设计为http://acme.com/employee/?company=X&title=Y&non-smoker=Z&T=U. 我不会硬说公司是强制性的：您的 API 将更容易更改。
但是，您应该考虑到少数“大”请求比大量小请求要快得多。此外，可以有效地缓存 URI 表示。因此，通常最好使用基于 ID 的 URI（因为有更多机会再次询问它们）。因此，您可以获取公司的完整员工列表（以及有关公司本身的其他数据），http://acme.com/company/X然后在客户端对其进行过滤。
我不知道是否有更好的方法，因为它通常取决于您使用的技术及其习语。
但是，这是我喜欢的两种不同的 URI 设计（以及为什么）
#1 GET https://api.website.com/v1/project/employee/{company-id}?title={title-id}&non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3>
#2 GET https://api.website.com/v1/project/company/{company-id}/employee?title={title-id}&non-smoker={true|false}&<name1>=<value1>&<name2>=<value2>&<name3>=<value3>
正如您在两个示例中看到的那样，我从查询字符串中提取了 company-id 。我更喜欢在路径信息中添加强制参数来区分它们。然后，在第二个 URI 中，员工资源嵌套在公司中。这样您就可以很容易地猜到您可以检索特定公司的所有员工，这在第一个示例中并不明显。
您是否正在创建一个新的员工对象？如果是这样，那么 POST（创建）更合适。一个很好的线索是您在 URL 中推送的所有数据。所有这些都应该在 POST 对象的主体中。