我有类似的REST API URL结构:
/api/contacts GET Returns an array of contacts
/api/contacts/:id GET Returns the contact with id of :id
/api/contacts POST Adds a new contact and return it with an id added
/api/contacts/:id PUT Updates the contact with id of :id
/api/contacts/:id PATCH Partially updates the contact with id of :id
/api/contacts/:id DELETE Deletes the contact with id of :id
我的问题是关于:
/api/contacts/:id GET
假设除了通过ID获取联系人之外，我还希望通过唯一别名来获取联系人。
如果我希望能够通过ID或Alias获取联系人，URI结构应该是什么？
最佳答案
IRI的路径和查询部分由您决定。该路径用于分层数据，例如api/version/module/collection/item/property，查询用于非分层数据，例如?display-fields="id,name,etc..."或?search="brown teddy bear"&offset=125&count=25等。
您要记住的是，您正在使用资源而不是操作。因此，IRI是资源标识符(例如DELETE /something)，而不是操作标识符(例如POST /something/delete)。您不必遵循IRI的任何结构，例如，您可以简单地使用POST /dashuif328rgfiwa。服务器会理解，但是为这种IRI编写路由器要困难得多，这就是为什么我们使用漂亮的IRI的原因。
重要的是，单个IRI始终仅属于单个资源。因此，您不能使用GET /cats/123来读取cat属性，而不能使用PUT /cats/123来写入dog属性。 ppl通常不了解，一个资源可以具有多个IRI，因此/cats/123，/cats/name:kitty，/users/123/cats/kitty，cats/123?fields="id,name"等等可以属于同一资源。或者，如果您想给某个事物(活猫，而不是描述它的文档)提供IRI，则可以使用/cats/123#thing或/users/123#kitty等。通常在RDF文档中进行操作。
它可以是/api/contacts/name:{name}，例如/api/contacts/name:John，因为它显然是分层的。或者，您可以检查/api/contacts/{param}中参数是否包含数字或字符串。
您也可以使用查询，但我不建议这样做。例如，以下IRI可以具有2个单独的含义:/api/contacts?name="John"。您想列出每个姓名为John的联系人，或者想要一个确切的联系人。因此，您必须在服务器端应用程序的路由器中就此类请求制定一些约定。