0

这就是我的 Jersey Rest web 服务的一些方法的样子，我有一些方法来更新用户设置，例如：

@PUT
@Path("/langauge")
@Consumes("text/plain")
public void updateLanguage(String lang) {

    ***check validity of the lang by string comparisons**
     and update database with the new language*
}

@PUT
@Path("/threshold")
@Consumes("text/plain")
public void updateThreshold(Long threshold) {

   *//check value and update in server*
}

现在我有几个问题；

1-而不是针对不同的更新选项使用不同的资源路径，创建一个资源并使用查询参数进行更新会更好吗？这看起来更 Restish 但我不确定我是否真的应该将其更改为类似的东西，因为将来如果有更多的参数需要更新，它会非常混乱，而拥有独立的路径看起来更清晰？

@PUT
@Path("/settings/{lang}/{threshold}")
@Consumes("text/plain")
public void updateSettings(@PathParam("threshold") String thre,
        @PathParam("lang") String lang,
        @DefaultValue("") @QueryParam) {


}

2-另一个问题是在更新语言时，我现在接受一种语言作为字符串，然后检查服务器中是否有效，所以当客户端使用这种方法时，他们不知道他们究竟应该发送什么作为有效参数。有没有办法让这对用户更加友好，在 WADL 文件上添加一些评论是一种选择，但是还有另一种更多的 REST 方式吗？

4

2 回答 2

1

我想说，在不了解应用程序的整个范围的情况下，您可以将设置视为资源，并将特定选项视为设置集合的成员。这将允许添加新设置（缺点是，想要更新多个设置的客户端需要知道并调用所有设置）：

/settings/language
/settings/threshold
...
# later
/settings/timeout
/settings/temperature

您可以GET在每个选项上实现该方法，以向感兴趣的客户端显示信息（以 HTML 或文本或其他格式）。

另一种方法是在一个端点收集所有设置并以某种格式（例如 JSON）接受请求实体作为所有可用设置的表示。这种方法可以在 elasticsearch API 中广泛使用（例如：http ://www.elasticsearch.org/guide/reference/api/admin-indices-update-settings.html ）。

于 2013-01-04T11:48:59.943 回答
0

答案：

1）由于它们是独立的资源，它们应该具有独立的服务方法。所以早期的方法很棒。这使您的代码灵活。

2）您可以为每个资源（在这种情况下为语言）提供唯一的 ID，并使用它来更新语言，例如：

api/language/{languageId}

这个 ID 可以通过数据库自动生成，或者您可以定义一些其他机制。

于 2013-01-04T13:10:29.167 回答