这是否实现了RESTFUL API?

时间:2016-10-06 17:01:07

标签: rest

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

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

谢谢!

2 个答案:

答案 0 :(得分:1)

  

以最纯粹/最简单的形式,以任何方式考虑这是一个" RESTFUL API"。

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,因为并非所有必需的约束都得到满足。

答案 1 :(得分:0)

甚至没有必要发送#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由四个接口约束定义:资源识别;通过陈述来处理资源;自我描述性的信息;并且,超媒体作为应用程序状态的引擎。