REST API使用GET PARAMS

假设我们有以下服务器资源：REST API使用GET PARAMS

api.example.com/event/1

它返回一些任意的资源，说：

{ 
    id: 1, 
    details: { 
     type: 'webinar', 
     .... 
    }, 
    attendees: [ 
     { 
      user_id: 1, 
      first_name: 'Bob' 
      ... 
     }, 
     ... 
    ] 
}

为客户做出的请求可能是有用的只获取事件的事件细节，而不是与会者列表。

如果客户端需要这两种资源，为资源提供两个单独的URL并强制两个单独的请求是否更好？

api.example.com/event/{event_id} 
api.example.com/attendees/{event_id}

或者是更好地提供相同的两个端点，而是选择性地具有第一个支持GET参数去切换与会者上市或关闭

api.example.com/event/{event_id}?listAttendees={true|false} 
api.example.com/attendees/{event_id}

凡listAttendees参数将不得不该表示返回与会者列表或不。

是否允许GET参数更改从特定URL返回的表示形式？

来源

2014-10-30 moesef

客户是否想要一个没有事件详细信息的参加者列表？ – Centinul 2014-10-31 00:18:13

我会为两个不同的URS，因为它完全符合REST，并且您要求两种不同的资源，可以通过两个不同的URI进行标识。 – 2014-10-31 00:20:16

@Centinul您可能想要缓存事件详细信息和与会者列表。例如，如果事件详细信息不会改变，但与会者列表可能会改变。 – moesef 2014-10-31 18:27:34

我想说在REST中最正确的方法是使用不同的媒体类型或媒体类型参数，但由于大多数人不使用自定义媒体类型，我经常使用我称之为缩放协议。这个想法是，你有一个zoom或expand参数，带有一个数值，它递归地包含子实体，减少参数直到它达到零。

所以，像一个请求：

GET api.example.com/event/1

返回事件资源平原表示，没有任何嵌入。一个请求，如：

GET api.example.com/event/1?zoom=1

将包括事件的直接子女，在你的情况下，出席者。以下是：

GET api.example.com/event/1?zoom=2

将包括事件的直接子女，出席者的直接子女。

要回答你的问题，在REST中，整个URI是一个原子标识符，所以参数是URI的一部分。如果你使用的东西不会以同样的方式解释URI，就像老的缓存服务器不会使用查询字符串缓存URI一样，这可能是一个问题。

来源

2014-10-31 02:56:24

REST API使用GET PARAMS

回答

相关问题