这似乎是一个奇怪的问题,但我想得到其他一些开发人员的意见。这提出了我们可能面临的一些潜在的专利问题。
我在互联网上安装了一个电子设备(安装在客户现场),每隔T秒轮询一次我们的服务器。每个设备都有一个唯一的序列号,每个设备轮询的URL都是唯一的(根据URL末尾的序列号):
每T秒轮询一次:
http://example.com/device/SERIAL_NUMBER
我们的服务器只返回“0”或“1”。从字面上看,如果你点击了URL,你会在浏览器中看到0或1。
这个“0”或“1”只是告诉我们的设备开启和关闭。基本上它是一个远程“开关”来打开和关闭设备。当我们返回0时,退出,当我们返回1时,继续。
没有JSON,没有XML,只有0或1.
这会以最纯粹/最简单的形式,以任何方式考虑“RESTFUL API”。
我的想法是“不”,我们只是使用HTTP来轮询一个唯一的URL并打开/关闭二进制文件 - 而为了拥有一个RESTFUL API,你需要的不仅仅是点击一个URL并返回一点。
谢谢!
答案 0 :(得分:1)
以最纯粹/最简单的形式,以任何方式考虑这是一个" RESTFUL API"。
tl; dr
技术上没有。从法律上讲,这是另一回事。哪里有下水道有办法。 IANAL。
<强>原理强>
术语REST和RESTful的问题在于它们的定义是抽象的,并且正确如此,因为REST定义了架构模式,而不是详细的规范。根据创造该术语的Roy Fielding所说,REST由几个属性和约束条件定义。
因此,为了回答您的问题,我们需要了解通常被认为是RESTful系统的内容。然后我们可以评估您的系统是否符合此定义。
<强>定义强>
属性的
展示了属性,系统架构的可观察效果。属性是系统的体系结构,设计和实现的结果,并且RESTful系统通常期望至少实现这些属性中的大多数。然而,我认为,仅仅存在这些属性并不是对系统&#34; RESTfulness&#34;因为还有其他方法可以实现它们。
- 性能 - 组件交互可能是用户感知性能和网络效率的主要因素
- 可扩展性,支持大量组件和组件之间的交互。
- 统一界面的简单性
- 组件的可修改性,以满足不断变化的需求(即使在应用程序运行时)
- 服务代理之间组件之间的通信可见性
- 通过使用数据移动程序代码来实现组件的可移植性
- 可靠性是指在组件,连接器或数据中出现故障时系统级故障的阻力
来源:Wikipedia
约束
约束是定义系统架构的(必要和充分)元素。如果系统违反任何这些约束,则根据定义,它不能被视为REST系统。因此,约束更强烈地表明了系统的RESTfulness。
- 客户端服务器 - (...)关注点分离是客户端 - 服务器约束(...)
背后的原则- 无状态 - 客户端 - 服务器通信受到请求之间没有客户端上下文存储在服务器上的限制。
- 可缓存 - 与万维网一样,客户和中介可以缓存响应。
- 分层系统 - 客户端通常无法判断它是否直接连接到终端服务器(...)
- 按需代码(可选) - 服务器可以通过传输可执行代码来临时扩展或自定义客户端的功能。
- 统一界面 - 资源识别,通过表示操作资源,自描述消息,超媒体作为应用程序状态的引擎
来源:Wikipedia
<强>评估强>
属性的
结论:您的系统展示了RESTful设计的大部分属性。这是一个必要但不充分的迹象表明它实际上是RESTful。因此,让我们接下来检查一下约束:
约束
结论:您所描述的系统不满足REST架构状态的所有约束。即统一接口与所需范围不匹配 - 虽然它提供了统一的寻址方案(URI),但它不符合REST统一接口的其他元素。
<强>结论强>
在您的系统描述中,虽然每个设备使用HTTP作为协议和唯一URI确实会影响RESTful系统的大部分必要属性,但仅此不够它被认为是RESTful,因为并非所有必需的约束都得到满足。
答案 1 :(得分:0)
甚至没有必要发送#34;
响应此存储库是否由您加注
GET /user/starred/:owner/:repo
Status: 204 No Content
如果此存储库未加星标,则回复
GET /user/starred/:owner/:repo
Status: 404 Not Found
也就是说,作为一个REST api,它不是一个非常有趣的,因为它暗示这个特定的应用程序状态是你的协议中的最终状态 - 表示中没有任何链接作为进一步的可供性进展。
REST由四个接口约束定义:资源识别;通过陈述来处理资源;自我描述性的信息;并且,超媒体作为应用程序状态的引擎。