Restful 是仅适用于 Web 服务还是同时适用于 Web 服务和网页？
我读了很多 PHP 的 Restful 教程。
（我不想深入探讨为什么我不使用 RoR。这是因为团队更熟悉 PHP）
因为我们计划未来扩展 API，我读到实现 Restful Web 很重要服务。
我看过诸如
http: //www.gen-x-design.com/archives/create-a-rest-api-with-php/
显然，restful 是针对 Web 服务的。
那么对于网页呢？他们也能安静吗？
如果答案是否定的，请不要超出此范围并告诉我。谢谢。
我知道要使 url 看起来像 RESTFUL url，只需使用 mod_rewrite。然而，我非常确定，宁静的架构不仅仅是让网址看起来漂亮。
例如，我在名为 list.php 的网页上有一个项目列表。每个项目旁边都有一个删除链接。例如，list.php?id=1&deleteitem
发生的情况是，当有人单击 list.php?id=1&deleteitem 链接时，我当然会返回到同一个 list.php 文件并检查参数 deleteitem $_GET。
如果检测到，我将根据 $_GET 中的参数 ID 从数据库中删除。
之后我将重定向回 list.php，无需任何参数。
我想知道，如何让整个流程变得轻松？
我问这个问题是因为在 REST 中，要删除某些内容，您需要使用 HTTP 请求方法（DELETE）。
显然，在我的链接中，它们都只是简单的 Delete
请赐教。
我的编程能力不是很强，如果给出的建议能尽可能通俗一些就好了。
谢谢。
编辑
我有 2 个后续问题。
问题 1) 由于这是一个带有分页的项目列表，如果我想使其成为 RESTful，URL 会是什么样子？
问题 2）由于我将删除链接放在列表中的每一项旁边，我现在明白了，我应该使用
<form method="POST">
<input type=hidden name="_method" value="delete">
<input type="submit" >
</form>
它。
但是表格应该张贴到哪里？商品网址？ /items/{item-id}
但我想在成功删除数据库中的行后返回到此列表页面，显示成功消息。
当我用成功消息刷新此列表页面时，我还想避免弹出消息。
如果我回发到这个 list.php url，那么它不是 RESTful，是吗？因为下面的答案告诉我，每个项目都是一个需要自己的网址的资源。
请赐教。谢谢。
I read a lot of Restful tutorials for PHP.
(I don't want to go in depth into why I am not using RoR. It is due to the team being more familiar with PHP)
Because we are planning for future expansion into having APIs i read that it is important to implement Restful web services.
I have looked at tutorials such as
http://www.gen-x-design.com/archives/create-a-rest-api-with-php/
Apparently restful is meant for webservices.
What about for webpages? can they be RESTFUL as well?
if the answer is NO, please do not go beyond this line AND just tell me. Thank you.
i know to make the urls look like RESTFUL urls is to simply use mod_rewrite. However, i am quite sure, restful architecture goes beyond just making the urls look nice.
For eg, i have a list of items on a webpage called list.php . Each item has a delete link next to it. E.g., list.php?id=1&deleteitem
What happens is that when someone clicks on the list.php?id=1&deleteitem link, of course i go back to the same list.php file and check for the param deleteitem in $_GET.
If detected, i will then delete from database based on the param id in $_GET.
After which i will redirect back to list.php WITHOUT any params.
I am wondering, how do i make this whole flow RESTFUL?
I am asking because in REST, to make delete something you need to use HTTP request method (DELETE).
Clearly in my links they are all just simply <a href="list.php?id=1&deleteitem">Delete</a>
Please enlighten me.
My programming is not that strong and it would be good if the advice given can be as layman as possible.
Thank you.
EDIT
I have 2 follow up questions.
question 1) Since this is a list of items with paging, how would the URL look like if i want to make it RESTful?
question 2) Since i am putting DELETE links next to every one of the items in the list, I understand now, i should use
<form method="POST">
<input type=hidden name="_method" value="delete">
<input type="submit" >
</form>
instead.
however the form should be posted to where? the item url? /items/{item-id}
But i want to go back to this listing page displaying a success message AFTER successfully deleting the row in database.
I also want to avoid a popup message when i refresh this listing page with success message.
If i post back to this list.php url, then it is not RESTful yes? because i am told by the answers below that each item is a resource which needs its own url.
Please enlighten me. Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
长答案简短：是的。休息是为了两者。这是因为，即使您拥有所有网站中最简单的网站，人们仍然需要获取您的页面，并且可能需要发布个人数据才能向留言簿添加条目。我们都以某种方式坚持 REST。
在您的情况下，糟糕的浏览器实现使得很难实现纯粹的 RESTful 方式。如果没有 Javascript，则不支持 DELETE，因此您必须使用 GET 或 POST（这两者与 REST 中的 DELETE 具有完全不同的含义）。
Long answer short: yes. REST is for both. That's because even if you have the simplest of all websites one would still have to GET your page and maybe POST ones personal data to add an entry to the guestbook. In that we all adhere to REST somehow.
In your case poor browser implementation makes it hard to implement a PURE RESTful way. DELETE isn't supported without Javascript and therefore you would have to use GET or POST (which both do have a totally different meaning from DELETE in REST) anyway.
Restful 方法当然也可以用在网页中。由于您提到的副作用，将命令放在 URL 中并不是一个好主意。当您更改数据库（或执行任何更改模型的操作）时，请使用 POST 命令。
当然，主流网络浏览器中没有 PUT 和 DELTE，但您始终可以发送带有某些特定参数的简单 POST，例如
method= "PUT",method=“删除”等Restful approach can surely be used in web pages as well. Putting commands in an URL is not a good idea, due to the side effects you are mentioning. When you change the database (or do whatever that changes the model), use POST commands.
Of course, you don't have PUT and DELTE in major web browsers, but you can always send a simple POST with some specific parameter like
method= "PUT",method="DELETE" etc.我在 Zend Framework 之上编写了一个小型框架，以便更轻松地实现 RESTful 接口：
http://github.com/mikekelly /Resauce
您可以将其用于网络服务和网站。本质上，网站只是由 HTML 驱动的 Web 服务。
I wrote a tiny framework on top of Zend Framework to make implementing RESTful interfaces easier:
http://github.com/mikekelly/Resauce
You can use that for web services and websites. Essentially, a website is just a web service driven by HTML.
RESTful 并不意味着“美丽的 URI”。尽管 URI 标识资源，但 REST 关于 URI 的唯一说明是，它们不应包含“删除”等操作参数。
在您的情况下，您会调用
答案通常是状态代码
200 OK，并将修改后的列表作为消息正文。请参阅：http://restpatterns.org/HTTP_Methods/DELETE由于 HTML 4 不支持其他形式与 GET 和 POST 相比，您必须使用隐藏参数来解决问题并覆盖服务器端的 HTTP 方法。
RESTful means not "beautiful URIs". Despite the fact that URIs identify a resource the only thing REST says about URIs is, that they shouldn't contain an action paramater like "delete".
In your case you would call
The Answer would be typically status code
200 OKwith the modified list as message body. See: http://restpatterns.org/HTTP_Methods/DELETESince HTML 4 doesn't support other form actions than GET and POST you have to workaround with a hidden paramater and override the HTTP method on the server side.
RESTful 通常在提及 Web 服务时使用，但它也可以很好地应用于网页。简而言之，RESTful 就是处理资源。资源可以是一个人、一本书、一部电影、一个剧院、一张门票或任何你喜欢的东西。
您可以对资源执行四种基本操作。
大多数 Web 浏览器不支持
PUT和DELETE操作，因此您只能使用 POST 操作发送数据。 Rails 通过传入一个名为_method的隐藏参数来伪造 PUT 和 DELETE，框架会根据该值拾取并路由它。另外，您永远不应该使用
GET进行任何破坏性操作。任何更改资源状态的操作都应根据更改调用POST、PUT或DELETE（如果需要的话，用 POST 来伪造 PUT/DELETE）。我建议您检查一下 Rails 中处理 RESTful 路由的方式，只是为了了解一下，如果没有其他的话。尽管上述四个操作足以以任何可能的方式修改资源，Rails 还引入了其他三种听起来有用的操作类型。
资源）
更新现有资源）
在设计 RESTful 站点时，漂亮的 URL 肯定是摆在桌面上的，但最大的胜利可能是代码质量自动提高。当您只处理资源时，并且只有四种可以应用于资源的潜在操作，那么事情就会开始自行清理。
编辑1：
自描述性 URL 是首选，它会让您的生活更轻松，但是创建唯一标识资源并使用 HTTP 动词管理它的神秘 URL 是没有什么问题的。像下面这样的 URL（使用 md5）来唯一标识资源是完全 RESTful 的。
这就是代表性状态转移。 MD5 哈希就像保持不变的资源的邮寄地址。该表示可以是电影的详细信息（以 html/xml/json/ 等形式），也可以是电影本身的视频，具体取决于客户端的功能）。
编辑2：
假设您有一个资源，它是世界
国家的集合。它可以用 URI 和 HTTP 动词表示，例如：
由于分页是应用程序的属性而不是资源本身，因此您可以提供查询字符串参数来控制它。
国家也是一种资源，是国家资源的一部分。您可以使用 URL 来标识一个国家/地区，例如：
并且可以使用以下动词执行对该国家/地区的操作：
RESTful is commonly used when referring to web services, but it can very well apply to web pages. In a nutshell, being RESTful is about dealing with resources. A resource can be a person, a book, a movie, a theatre, a ticket, or whatever you fancy.
There are four basic operations you could perform on a resource.
Most web browsers do not support the
PUTandDELETEactions, so you can only use POST actions for sending data. Rails fakes PUT and DELETE by passing in a hidden parameter named_methodthat the framework picks up and routes it depending on that value.Also, you should never use
GETfor any destructive action. Any action that changes the state of your resource(s), should be called with eitherPOST,PUT, orDELETEdepending on the change (fake PUT/DELETE with POST if need be).I would suggest you checkout the way RESTful routing is handled in Rails just to get an idea, if nothing else. Althought the four actions above are sufficient to modify a resource in any way possible, Rails also introduces three other types of actions that sound useful.
resource)
update an existing resource)
Pretty URL's is definitely on the table when designing RESTful sites, but probably the biggest win is that the quality of code improves automatically. When you're only dealing with resources, and there are only four potential actions that can be applied to a resource, then things start to clean up by themselves.
Edit 1:
Self-descriptive URL's are preferred and will make your life easier, but there's nothing stopping from creating cryptic URLs that uniquely identify a resource and manage it using the HTTP verbs. URLs such as the ones below (using md5) to uniquely identify resources are perfectly RESTful.
That's REpresentational State Transfer right there. The MD5 hash is like the mailing address of the resource that remains constant. The representation could be the movie's details (in html/xml/json/etc.), or maybe the video of the movie itself depending on the capabilities of the client).
Edit 2:
Let's say you have a resource which is a collection -
countriesof the world.It could be represented by a URI and HTTP verb such as:
Since paging is a property of the application rather than the resource itself, you could supply querystring parameters to control it.
A country is also a resource that is a part of the countries resource. You could identify a country with a URL such as:
And operations on this country could be performed with these verbs: