我希望这不是一个愚蠢的问题,但今天我收到一条评论,说必须通过用户友好的 url 访问 PHP Web 服务才能被视为 RESTful。这是真的?
谢谢!
用户友好的 url 没有明确定义,因此不能有这样的约束。用户友好取决于用户。没有这样的限制,HTTP 是 RESTful 并且有很多非“用户友好”的 url。
好吧,并不是说Wikipedia Restful Information是万能的,但是根据定义的约束,用户友好的 url 不是其中之一。
REST 架构风格描述了应用于架构的以下六个约束,同时让各个组件的实现自由设计:
客户端服务器
统一的接口将客户端与服务器分开。这种关注点分离意味着,例如,客户端不关心数据存储,数据存储保留在每个服务器内部,从而提高了客户端代码的可移植性。服务器不关心用户界面或用户状态,因此服务器可以更简单且更具可扩展性。服务器和客户端也可以更换和独立开发,只要不改变它们之间的接口即可。
无状态
客户端-服务器通信进一步受到请求之间没有客户端上下文存储在服务器上的限制。来自任何客户端的每个请求都包含服务请求所需的所有信息,并且任何会话状态都保存在客户端中。服务器可以是有状态的;此约束仅要求服务器端状态可通过 URL 作为资源寻址。这不仅使服务器对监控更加可见,而且使它们在面对部分网络故障时更加可靠,并进一步增强了它们的可扩展性。
可缓存
与万维网一样,客户端可以缓存响应。因此,响应必须隐式或显式地将自己定义为可缓存或不可缓存,以防止客户端重复使用陈旧或不适当的数据来响应进一步的请求。管理良好的缓存部分或完全消除了一些客户端-服务器交互,进一步提高了可伸缩性和性能。
分层系统
客户端通常无法判断它是直接连接到终端服务器,还是一路连接到中间人。中间服务器可以通过启用负载平衡和提供共享缓存来提高系统可伸缩性。他们还可以强制执行安全策略。
按需编码(可选)
服务器能够通过传输可执行代码临时扩展或定制客户端的功能。这方面的示例可能包括已编译的组件(例如 Java 小程序)和客户端脚本(例如 JavaScript)。
统一的界面
下面讨论的客户端和服务器之间的统一接口简化和解耦架构,使每个部分能够独立发展。下面详细介绍该接口的四个指导原则。
REST 架构的唯一可选约束是按需代码。如果服务违反任何其他约束,则不能严格将其视为 RESTful。
遵守这些约束,从而符合 REST 架构风格,将使任何类型的分布式超媒体系统具有理想的新兴属性,例如性能、可伸缩性、简单性、可修改性、可见性、可移植性和可靠性。