即使我提供 PUT 和 DELETE 的替代方案(参见“低 REST”)，我如何为从浏览器访问我的 Web 服务的用户提供用户友好的表单验证，同时仍然公开 RESTful URI？表单验证问题(如下所述)是我目前的困惑，但我想问的更广泛的问题是:如果我尝试同时提供 RESTful 公共(public)接口(interface) 和 非 javascript HTML 界面，它会让生活更轻松还是更艰难？他们一起玩吗？
理论上，这应该仅仅是改变输出格式的问题。机器可以查询 URL“/people”，并获得 XML 格式的人员列表。人类用户可以将他们的浏览器指向相同的 URL，并获得漂亮的 HTML 响应。 (我正在使用 URL examples from the microformats wiki ，这看起来相当合理)。
创建新的人员资源是通过对“/people”URL 的 POST 请求完成的。为此，人类用户可以首先访问“/people/new”，它会返回用于创建资源的静态 HTML 表单。表单有 method=POST 和 action="/people"。如果用户的输入是有效的，那会很好地工作，但是如果我们在服务器端进行验证并发现错误怎么办？友好的做法是返回表单，填充用户刚刚输入的数据，加上一条错误消息，以便他们可以解决问题并重新提交。但是我们不能将输出直接从 POST 返回到“/people”，否则它会破坏我们的 URL 系统，如果我们将用户重定向回“/people/new”表单，那么就没有办法报告错误和重新填充表单(除非我们将数据存储到 session 状态，这会更不符合 REST 风格)。
使用 javascript，事情会容易得多。只需在后台执行 POST，如果失败则在表单顶部显示错误。但我希望应用程序在 javascript 支持不可用时优雅地降级。目前，我得出的结论是，如果没有 javascript，重要的 Web 应用程序无法实现 HTML 界面，并且使用传统的 RESTful URL 方案(例如微格式 wiki 上描述的方案)。如果我错了，请告诉我!
关于 Stack Overflow 的相关问题(均未涉及表单验证):
最佳答案
您可以将 html 表单直接发布到/people/new。如果验证失败，请使用适当的信息重新呈现编辑表单。如果成功，将用户转发到新的 URL。这与我理解的 REST 架构是一致的。
我看到你对 Monis Iqbal 发表评论，我不得不承认我不知道你所说的“非 RESTful URLS”是什么意思。 REST 架构对 URL 的唯一要求是它是不透明的，并且它与资源唯一配对。 REST 不关心它看起来像什么、里面有什么、斜线或使用方式、使用了多少或类似的东西。 URL 的可见设计由您决定，与 REST 无关。
关于RESTful Web 服务的 HTML 接口(interface) *无需* javascript，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1269816/