Question

这似乎是一个奇怪的问题，但我想得到其他一些开发人员的意见。这提出了我们可能面临的一些潜在的专利问题。

我在互联网上安装了一个电子设备（安装在客户现场），每隔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并返回一点。

谢谢！

Answer 1

以最纯粹/最简单的形式，以任何方式考虑这是一个＆＃34; RESTFUL API＆＃34;。

tl; dr

技术上没有。从法律上讲，这是另一回事。哪里有下水道有办法。 IANAL。

<强>原理

术语REST和RESTful的问题在于它们的定义是抽象的，并且正确如此，因为REST定义了架构模式，而不是详细的规范。根据创造该术语的Roy Fielding所说，REST由几个属性和约束条件定义。

因此，为了回答您的问题，我们需要了解通常被认为是RESTful系统的内容。然后我们可以评估您的系统是否符合此定义。

<强>定义

属性的

展示了属性，系统架构的可观察效果。属性是系统的体系结构，设计和实现的结果，并且RESTful系统通常期望至少实现这些属性中的大多数。然而，我认为，仅仅存在这些属性并不是对系统＆＃34; RESTfulness＆＃34;因为还有其他方法可以实现它们。

性能 - 组件交互可能是用户感知性能和网络效率的主要因素

可扩展性，支持大量组件和组件之间的交互。

统一界面的简单性

组件的可修改性，以满足不断变化的需求（即使在应用程序运行时）

服务代理之间组件之间的通信可见性

通过使用数据移动程序代码来实现组件的可移植性

可靠性是指在组件，连接器或数据中出现故障时系统级故障的阻力

来源：Wikipedia

约束

约束是定义系统架构的（必要和充分）元素。如果系统违反任何这些约束，则根据定义，它不能被视为REST系统。因此，约束更强烈地表明了系统的RESTfulness。

客户端服务器 - （...）关注点分离是客户端 - 服务器约束（...）
背后的原则
无状态 - 客户端 - 服务器通信受到请求之间没有客户端上下文存储在服务器上的限制。

可缓存 - 与万维网一样，客户和中介可以缓存响应。

分层系统 - 客户端通常无法判断它是否直接连接到终端服务器（...）

按需代码（可选） - 服务器可以通过传输可执行代码来临时扩展或自定义客户端的功能。

统一界面 - 资源识别，通过表示操作资源，自描述消息，超媒体作为应用程序状态的引擎

来源：Wikipedia

<强>评估

属性的

性能 - 是，从一般意义上讲，您的系统性能取决于网络性能（糟糕的网络性能意味着设备会在延迟时间内打开/关闭，或者根本不打开）。
可扩展性 - 是，显然您的系统可以扩展到任意数量的设备，但不会对设备本身产生影响。
统一界面的简单性 - 是，每个设备的URI
可修改性 - 是，可以更改设备和服务器，而不会影响其他设备和服务器
可见性 - 是，显然可以看到沟通，至少在某种程度上
便携性 - 是，0/1指令非常清楚可执行代码（设备的状态机将此作为导致其执行操作的事件，即关闭或者））
可靠性 - 可能，我们对您的系统了解不够

结论：您的系统展示了RESTful设计的大部分属性。这是一个必要但不充分的迹象表明它实际上是RESTful。因此，让我们接下来检查一下约束：

约束

客户端服务器 - 是，显然这是客户端 - 服务器设计，并且关注点是分开的（服务器：每个设备的开/关安排，设备：效果开/关操作）
无状态 - 是，服务器上没有存储客户端上下文。请注意，这是对通信状态的引用，而不是设备状态。
可缓存 - 是，这是使用http作为通信协议所固有的
分层系统 - 是，这是使用http作为通信协议所固有的
按需代码（可选） - 是，如上所述，0/1指令实际上可以被视为可执行代码。
统一界面 - 否，资源被清楚地识别，但是无法进行操作，并且没有超媒体存在，客户端可以允许导航资源。

结论：您所描述的系统不满足REST架构状态的所有约束。即统一接口与所需范围不匹配 - 虽然它提供了统一的寻址方案（URI），但它不符合REST统一接口的其他元素。

<强>结论

在您的系统描述中，虽然每个设备使用HTTP作为协议和唯一URI确实会影响RESTful系统的大部分必要属性，但仅此不够它被认为是RESTful，因为并非所有必需的约束都得到满足。

Answer 2

甚至没有必要发送＃34;

Github API

响应此存储库是否由您加注

GET /user/starred/:owner/:repo
Status: 204 No Content

如果此存储库未加星标，则回复

GET /user/starred/:owner/:repo
Status: 404 Not Found

也就是说，作为一个REST api，它不是一个非常有趣的，因为它暗示这个特定的应用程序状态是你的协议中的最终状态 - 表示中没有任何链接作为进一步的可供性进展。

来自Fielding's dissertation

REST由四个接口约束定义：资源识别;通过陈述来处理资源;自我描述性的信息;并且，超媒体作为应用程序状态的引擎。

这是否实现了RESTFUL API？

2 个答案: