Question

这是我的Jersey Rest网络服务的一些方法看起来很喜欢，我有一些方法来更新用户设置，如：

@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方法吗？

Answer 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）。

Answer 2

答案：

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

2）您可以为每个资源（在本例中为语言）提供唯一ID，并使用它来更新语言，如：

api/language/{languageId}

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

Java REST服务PUT参数

2 个答案: