REST 风格 URL 的首选方法？
我正在创建一个包含 REST 风格服务的 Web 应用程序，我想澄清一下我的 Java 服务器端应如何接受 POST 请求的首选（标准）方法：
方法 1： http://localhost:8080/services/processser/uid/{uidvalue}/eid/ {eidvalue}
方法2： http://localhost:8080/services/processuser {uid:"",eid:""} - 这将在帖子正文中作为 JSON 发送
这两种方法都会使用“application/json”内容类型，但是每种方法都有优点和缺点。我立即想到的方法 2 的一个缺点是 JSON 数据需要映射到 Java 对象，从而在任何用户访问“processuser”servlet api 时随时创建一个 Java 对象。非常感谢您的意见。
在此特定实例中，数据将用于查询数据库，以将 json 响应返回给客户端。
I am creating a web application that incorporates REST-style services and I wanted some clarification as to the preferred (standard) method of how the POST requests should be accepted by my Java server side:
Method 1:
http://localhost:8080/services/processser/uid/{uidvalue}/eid/{eidvalue}
Method 2:
http://localhost:8080/services/processuser
{uid:"",eid:""} - this would be sent as JSON in the post body
Both methods would use the "application/json" content-type, but are there advantages, disadvantages to each method. One disadvantage to method 2, I can immediately think of is that the JSON data, would need to be mapped to a Java Object, thus creating a Java object any time any user access the "processuser" servlet api. Your input is much appreciated.
In this particular instance, the data would be used to query the database, to return a json response back to the client.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为我们需要从你的问题上回顾一下。您的路径段开头为：
这是一个错误。 URI 应标识资源，而不是操作。这可能并不总是可行，但这是您应该努力争取的。
在这种情况下，您似乎使用
uid和eid（无论它们是什么）来标识您的用户。您可以构建路径，例如用户由/user// 、/user/- 引用> （如果您必须/user/uid//eid/ ）；如果eid是一个专业化，并且与uid不处于同等地位，则/user/;eid= 会更合适。如果您事先知道标识符，则可以通过发布到
/user/或/user// 来创建新用户，并使用以下方法删除用户DELETE/user// 并使用 PUT 更改状态/user// 。因此，要回答您的问题，如果“processuser”旨在使用您提供的数据更改用户的状态，则应该在
/user// 上使用 PUT。否则，到 REST 模型的映射不是那么干净，可能最好的选择是定义一个资源/user/process// 并在其中发布所有数据，但是将所有数据发送到/user/process或多或少是相同的，因为我们已经处于类似 RPC 的阵营中。I think we need to go back a little from your question. Your path segment starts with:
This is a mistake. The URI should identify a resource, not an operation. This may not be always possible, but it's something you should strive for.
In this case, you seem to identify your user with a
uidand aneid(whatever those are). You could build paths such as a user is referred to by/user/<uid>/<eid>,/user/<uid>-<eid>(if you must/user/uid/<uid>/eid/<eid>); ifeidis a specialization, and not on equal footing withuid, then/user/<uid>;eid=<eid>would be more appropriate.You would create new users by posting to
/user/or/user/<uid>/<eid>if you knew the identifiers in advance, deleting users by using DELETE on/user/<uid>/<eid>and change state by using PUT on/user/<uid>/<eid>.So to answer your question, you should use PUT on
/user/<uid>/<eid>if "processuser" aims to change the state of the user with data you provide. Otherwise, the mapping to the REST model is not so clean, possibly the best option would be to define a resource/user/process/<uid>/<eid>and POST there with all the data, but a POST to/user/processwith all the data would be more or less the same, since we're already in RPC-like camp.对于 POST 请求，通常首选方法 2，尽管资源名称通常会采用复数形式，以便您实际上发布到：
但是，这是为了创建新记录。
看起来您确实正在使用大多数 RESTful 服务使用 GET 请求（检索记录）的功能，在这种情况下，首选方法 1。
编辑：
我意识到我没有提供答案，因此请考虑 Rails 设定的标准。您可能同意也可能不同意这是一个有效的标准。
For POST requests, Method 2 is usually preferred, although often the resource name will be pluralized, so that you actually post to:
This is for creating new records, however.
It looks like you're really using what most RESTful services would use a GET request for (retrieving a record), in which case, Method 1 is preferred.
Edit:
I realize I didn't source my answer, so consider the standards set by Rails. You may or may not agree that it is a valid standard.