Question

我的实体名为 Item 。

POST     /api/items          create a new Item
PUT      /api/items/{id}     update an existing Item
GET      /api/items/{id}     get Item by id

但是，我需要以三种不同模式检索项目：最近（通过纬度，经度和距离），收藏夹（由 isFavorite 标记标记）和个人（由用户插入）。

我虽然可以命名这三个网址：

GET      /api/items/nearest?latitude=xxx&longitude=xxx&distance=xxx
GET      /api/items/favorite
GET      /api/items/personal

但是当我读到这可能违反了REST命名约定。我应该使用类型参数（一种枚举）？但是这样用户可以调用GET /api/items?type=favorite&latitude=xxx&longitude=xxx&distance=xxx，这没有意义。

最后一个问题：Twitter API似乎不遵守REST命名约定，使用POST statuses/update或GET direct_messages/sent等端点。你怎么看待这个？

Answer 1

REST不是一个标准 - 它是一个概念，所以实际上你不能粗暴地违反它。

但在你的情况下，我建议再增加一条GET路线

GET /api/items?type=favorite|personal|nearest&...

并将您的“模式”作为获取查询传递，而不是将其与id

混合

Answer 2

REST没有URI命名约定。

我看到支持

的问题

GET /api/items/{id} 
GET /api/items/favorite

它是否会让客户感到困惑，因为有时/items之后的路径段是指示单个资源的ID，有时它是指示组资源的名称。

我看到支持

的问题

GET /api/items?type=favorite&latitude=xxx&longitude=xxx&distance=xxx

正如您所认识到的那样，让客户端进行令人困惑的调用是有问题的，因为某些查询参数可能会或可能不会应用于结果。

在我看来，问题实际上是最近的项目，因为这需要一组在其他上下文中没有意义的查询参数。另一种选择是使用单独的顶级端点。

GET /api/items/{id}?favorite=true&personal=false
GET /api/nearest-items/latitude=xxx&longitude=xxx&distance=xxx
    [optional ?favorite and ?personal query params]

请注意，如果您添加了一些其他需要多个查询参数的选择条件，这将会非常糟糕。

编辑-----

嗯。另一种选择是将三个可选的最近参数混合成一个。

GET /api/items?nearestTo=12.34,54.40,5&favorite=true

这不是人类可读的，但人类真的会读你的URI吗？

RESTful服务和命名约定

2 个答案: