服务器端的 RESTful Web 服务答案

【问题标题】：RESTful Web Serice on the Server-Side服务器端的 RESTful Web 服务
【发布时间】：2012-03-27 14:23:20
【问题描述】：

我是一名尝试开始开发 Web 服务的 C++/Java 人员。我已经阅读了很多关于 RESTful 服务的内容，并且我了解架构以及 URI 应该如何形成，并且我认为我了解客户端的内容，因为这就是我找到的地址。我的问题可能更基本 - 如果我有这样的 URI：

http://www.mysite.com/products/gadgets/spypen

如何在服务器端进行设置？在我（显然是最小的）Web 编程经验中，我会在 HTTP 根目录下有一个名为“products”的目录，然后在该目录下有一个名为“gadgets”的子目录，然后是一个包含 index.html 的子目录“spypen”。显然，这不是在这种情况下这样做的方法。

在我看来，我想告诉我的（基于 Linux 的 Apache）网络服务器解释它收到的 URI，然后调用带有“gadgets”和“spypen”参数的特定 PHP 脚本（或其他） ”。我可能只是在错误的地方寻找，但我找不到任何资源来告诉我在服务器端做什么以在 Apache 接收到 URI 时使用这些参数调用 PHP 脚本。任何帮助将不胜感激，我希望我不是在问一个完全愚蠢的问题，但我很确定我是...... :-) 谢谢！

【问题讨论】：

标签： rest server-side

【解决方案1】：

Recess is a PHP framework 用于直接处理 HTTP 请求。在 Java 世界中，您应该查看 cmets 并回答 SO question 以获取选项。在您尝试手动推出自己的实现之前，查看这些框架至少可以让您了解所涉及的内容。

【讨论】：

Recess 看了一眼可能会很有趣。我似乎对它有一些参考，但不清楚它的用途。有没有办法不需要一些现成的框架？也许是我想太多了。 WADL 会让我这样做吗？这是我的第一个想法，但大多数关于 WADL 的 cmets 都非常消极。
记录静态“服务契约”通常是 WADL 在基于 HTTP 的应用程序上下文中受到批评的原因。如果你真的利用 HTTP 规范，“服务契约”的作用是由媒体类型定义来扮演的。使用 WADL 变成了对肥皂机制的更简单的重新散列。一个好的 HTTP 应用程序应该以更加动态、自我描述的方式编写。围绕如何设计这些符合 REST 的应用程序存在主要的“争论”。如果您务实，请挑选适合您的方法，同时了解您为何忽略公认的“最佳实践”。
所以，进一步看，我认为这不是我真正想要的。我的系统将仅是 GET，因此客户端可以从服务器获取数据。我真正想要的是在服务器上接收 URI，并且根据 URI，调用 N 个 PHP 函数之一。我之前使用 SOAP 和 WSDL 文件进行了此操作，效果很好，但我一直听说 REST 更容易，但我不确定如何以 RESTful 方式模仿相同的行为。
一个属于 REST 架构风格的元素，我认为您正在寻找的是 hypermedia linking. 这意味着来自您的服务的每个响应都包含指向该响应的允许操作的“链接” .您控制发送到客户端的链接，并且其逻辑被编码为跟随响应中的链接。在肥皂世界中，所有这些动作都必须在 WSDL 中预定义为肥皂动作。在 REST 世界中，链接是控制客户端逻辑并动态创建的操作。
由于它的实用性而接受您的答案 - 仍然不是我所追求的。相反，我最终只是解析了 php 脚本中的 URI，这对我有用，但可能不是公认的这样做的方式。所以我将问题的 URL 更改为 mysite.com/products.php/gadgets/spypen 之类的东西，然后在 products.php 中我做了一些字符串解析以从 $_SERVER["REQUEST_URI"] 中提取“gadgets”和“spypen”，然后使用这些提供的值进行查询适当的数据库并形成对请求的响应..