RESTful的操作方式

2023年1月20日 268次阅读

我想拥有RESTful接口,它不会破坏REST原则.这是更多的讨论问题,你将如何做到这一点,你认为什么是最好的解决方案.想象一下这个应用场景.

应用程序具有典型的用户和他们聚集的房间进行交互.每个HTTP请求都包含HTTP基本认证头,它带来用户与资源交互的信息.让我们想一下/ rooms URL下的房间资源.我希望有RESTful方法URI来处理用户创建空间时的操作(并且不加入他,只提供可以加入这个房间的数据),加入房间和左侧房间.我想到的是：

创造空间

POST /rooms --data {room data}

加入并离开房间看起来像下面的代码,

PUT/DELETE /rooms/{roomId}/{userId}

正如您所看到的,我需要传递userId,它应该是来自HTTP头的上下文信息,因此我不应该在URL中传递它.这里的问题是,在创建房间期间我让用户进入房间,但他们有“未加入”状态.所以在创建之后(到目前为止没有执行任何连接),实际上有IS / rooms / {roomId} / {userId}资源.知道怎么做得好吗？:-)

最佳答案 你的资源是一个房间所以首先你必须考虑：

POST /room

没有’s’.响应将返回Content-Location：/ room / {roomId}标头,表示您的房间URI.

GET /rooms

列出所有房间.

然后,您可以考虑加入操作的资源URI：

/room/{roomId}/join/{joinId}

对于用户加入特定房间：

POST /room/{roomId}/join --data <join userId="{userId}" />
Response header : **Content-Location : /room/{roomId}/join/{joinId}**

并且对于用户离开特定房间：

DELETE /room/{roomId}/join/{joinId}

有关特定房间的“连接”列表：

GET /room/{roomId}/joins
Response content : 
<joins>
 <join id="888" userId="100" />
 <join id="889" userId="101" />
 <join id="890" userId="102" />
</joins>

对于特定用户：

GET /user/{userId} 
Response content : 
<user id="100" name="john" />

对于允许的用户：

POST /room/{roomId}/allowed 
--data 
<allowed>
 <user id="100">
 <user id="101">
 <user id="102">
 <user id="103">
</allowed>
点赞