这就是我的 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 的方式来做到这一点吗？
最佳答案
在不知道应用程序的整个范围的情况下，我想说，您可以将设置视为资源，并将特定选项视为设置集合的成员。这将允许添加新设置(缺点是，想要更新多个设置的客户端需要知道并调用所有设置):
/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 )。
关于Java REST 服务 PUT 参数，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/14156500/