RESTful 服务——如何设计一个有很多参数的 URL答案

【问题标题】：RESTful services - how to design a URL with many parametersRESTful 服务——如何设计一个有很多参数的 URL
【发布时间】：2013-04-08 17:20:34
【问题描述】：

我已经开发了 REST 服务，但现在我意识到我做错了什么。

例如，我有一项服务可以检索有关特定设备的信息。每个设备都有一个地址：sector.room.group.id。我为这个 GET 方法做的 URI 是：(...)/services_devices/{sector}/{room}/{group}/{id} 但现在我意识到我不应该使用'/' 来分隔设备地址，对吧？我应该如何将地址传递给这个方法？使用';' ?

我的 GET 方法是：

@GET
@Path("{sector}/{room}/{group}/{id}")
@Produces("application/json")
public String getDeviceName(@PathParam("sector") int sector, @PathParam("room") int room, @PathParam("group") int group, @PathParam("id") int id) throws Exception
{
    String name = null;

    try {
            name = new DevicesManager().getDeviceName(sector, room, group, id); 
    } catch (Exception e) {
            e.printStackTrace();
    }
    return name;
}

有一个简单的方法来改变这个，有一个正确的 URI？我在很多方法中都有这个“错误”。

【问题讨论】：

如果您只是将您的 URI 更改为 /services_devices/{address} 并开始接受您指定格式的地址，即 /services_devices/sector.room.group.id 怎么办？
嗯，你说得对！我需要解析这些字段，但我认为没有问题..
id 在您的应用程序中是唯一的，还是仅在指定组中唯一？换句话说，如果你只提供/services_devices/id，你能查到扇区、房间和组吗？
是的。例如，1.1.10.1 表示设备，1.1.21.1 表示不同的设备。
我的建议是，弃用这个 API 和新的 API，或者用正确的方法向这个 API 添加新版本。

标签： java rest uri restful-architecture

【解决方案1】：

如果您的资源中存在层次结构，则路径变量是合适的。

在您的情况下，设备和地址之间似乎存在层次结构，但首先是地址，然后是设备名称。 "deviceName" 可以被认为是一个更高层次的步骤。

反映上述关系的最佳方式是以下网址：

(...)/sector/room/group/id/deviceName

然后您可以像这样映射设备的另一个属性：

(...)/sector/room/group/id/deviceOwner

JAX-RS 映射为：

@GET
@Path("{sector}/{room}/{group}/{id}/deviceName")
@Produces("application/json")
public String getDeviceName(@PathParam ...) {
//impl.
}

是的，如果 deviceName 是资源的唯一相关属性，那么您可以省略“deviceName”并且您的原始映射是正确的。

如果/sector/room/group/id 的资源有很多属性，你应该考虑为路径返回一个组合对象：

@GET
@Path("{sector}/{room}/{group}/{id}")
@Produces("application/json")
public Device getDeviceName(@PathParam...) {
}

【讨论】：

好吧，现在我的第一种方法是有道理的，因为id 表示属于group 的设备，而该组属于room，属于sector .所以它是元素（参数）的层次结构，所以它们可以用/分隔。我说的对吗？
是的。试想一下，如果您有更多设备属性，而不仅仅是“deviceName”，也许您还有 deviceNumber、所有者等。如果是这种情况，请从 GET 方法创建并返回一个 Device 对象

【解决方案2】：

REST 架构风格引入了 HATEOAS，这意味着客户端和服务器是松散耦合的。只是客户端不知道 URL 的样子并从以前的响应中获取它们。（类似于浏览 HTML 页面）。当然，客户端至少会知道一个 URL，即入口点。从这个角度来看，您需要正确的 URI 是无关紧要的。什么是正确的 URI？当 URI 的形式与 RFC 一致时，该 URI 是正确的。

您可能正在引入非 RESTful 的 URL 模式，因为它暗示了客户端和服务器之间的紧密耦合（客户端必须了解 URL 模式并能够从它们构造 URL；填充扇区/房间/等。在你的情况下）

另见这篇文章：

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

我的建议是；不要在 URL 模式上浪费时间，尽可能简化 URL，扁平层次结构也有很多好处，并遵循 HATEOAS 原则。

【讨论】：