www.example.com/post/21/edit 是 RESTful URI 吗？我想我知道答案，但还有一个问题
我几乎不敢发布这个问题，肯定有一个我忽略的明显答案，但我在这里：
背景：我正在创建一个用于教育目的的博客（想学习 python 和 web.py）。我决定我的博客有帖子，所以我创建了一个 Post 类。我还决定可以创建、阅读、更新或删除帖子（因此 CRUD）。因此，在我的 Post 类中，我创建了响应 POST、GET、PUT 和 DELETE HTTP 方法的方法。到目前为止，一切都很好。
我当前遇到的问题是一个概念性的问题，我知道发送 PUT HTTP 消息（带有编辑后的帖子）到 /post/52 应该使用 HTTP 消息的正文内容更新 id 52 的帖子。
我不知道如何从概念上正确地提供（HTML）编辑页面。
这样做是否会违反 URI 的概念：/post/52/edit，因为“编辑”不是资源，而是操作？
但另一方面，它是否可以被视为资源，因为所有 URI 都会响应 GET 方法，而该方法只会返回 HTML 页面？
所以我的最终问题是：如何以 RESTful 方式提供供用户编辑的 HTML 页面？
I'm almost afraid to post this question, there has to be an obvious answer I've overlooked, but here I go:
Context: I am creating a blog for educational purposes (want to learn python and web.py). I've decided that my blog have posts, so I've created a Post class. I've also decided that posts can be created, read, updated, or deleted (so CRUD). So in my Post class, I've created methods that respond to POST, GET, PUT, and DELETE HTTP methods). So far so good.
The current problem I'm having is a conceptual one, I know that sending a PUT HTTP message (with an edited Post) to, e.g., /post/52 should update post with id 52 with the body contents of the HTTP message.
What I do not know is how to conceptually correctly serve the (HTML) edit page.
Will doing it like this: /post/52/edit violate the idea of URI, as 'edit' is not a resource, but an action?
On the other side though, could it be considered a resource since all that URI will respond to is a GET method, that will only return an HTML page?
So my ultimate question is this: How do I serve an HTML page intended for user editing in a RESTful manner?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
另一种 RESTful 方法是使用查询字符串作为修饰符：
/post/52?edit=1另外，不要太在意 REST 模型的纯粹性。如果您的应用程序不能完全融入该模型，请打破规则。
Another RESTful approach is to use the query string for modifiers:
/post/52?edit=1Also, don't get too hung up on the purity of the REST model. If your app doesn't fit neatly into the model, break the rules.
不存在 RESTful URI 这样的东西。这是错误的概念，因为 URI 应该对客户端完全不透明。
如果它可以帮助您通过避免 URI 中的动词来正确实现 HTTP 统一接口，那就太好了，但不要因为 URI 的外观而感到受限。将资源建模视为数据建模类型是非常有限的。 RESTful 系统通常需要做的不仅仅是 CRUD 操作，因此您需要在系统中提供哪些可用资源方面发挥创意。
如果创建 URL 并取消引用它会返回 200 状态代码，则该 URL 引用资源。如果您创建另一个 URL 并且它也返回 200，那么这是一个差异资源。
这意味着：
是4种不同的资源，也是
不同的资源。
因此，要回答您的问题，如果您这样做
并且它返回 200 状态代码和表示，那么它一定是资源。
There is no such thing as a RESTful URI. It is false concept as URIs should be completely opaque to the client.
If it helps you to properly implement the HTTP uniform interface by avoiding verbs in your URIs then that's great, but don't feel constrained by what your URI looks like. It is very limiting to think of resource modeling as type of data modelling. A RESTful system usually needs to do way more than just CRUD operations, so you need to be creative about what resources you make available in your system.
If you create a URL and dereferencing it returns a 200 status code, then that URL refers to a resource. If you create another URL and it also returns a 200, then that is a difference resource.
That means:
are 4 different resources, and
are also different resources.
Therefore to answer your question, if you do
and it returns a 200 status code and a representation, then it must be a resource.
如果您不将其称为
/post/52/edit，而是将其称为/post/52/editor，会怎样？现在它是一种资源。困境得以避免。
Instead of calling it
/post/52/edit, what if you called it/post/52/editor?Now it is a resource. Dilemma averted.
我不认为 /object/id/action 是 REST 规范的一部分。
您的编辑器是否会成为所有对象的通用编辑器？那么也许您的 URL 应该类似于
action 是一个 HTTP 动词 ( GET、PUT、DELETE、POST )，并且应该是 HTTP 请求的一部分，而不是 URL 的一部分。如需更好的总结，请查看这篇有关 RESTful_web_services 的维基百科文章。
I don't think /object/id/action is part of the REST specification.
Is your editor going to be a generic thing for all objects ? Then maybe your URL should look like
The action is an HTTP Verb ( GET,PUT,DELETE,POST ) and is supposed to be a part of the HTTP request and not part of the URL. For a better summary, check out this Wikipedia article on RESTful_web_services.