RESTful服务参数必须是可发现的吗？

Question

序言:我对REST的理解充其量是浅薄的,因此欢迎对我的问题进行任何更正或澄清.

我有一种情况,我需要RESTful服务的用户提交任意真正的正数.因此,我假设我不应该在url中要求它,即使返回的对象应该是相同的,并且应该使用参数(或者这个假设是错误的？).

鉴于此,为了符合REST,参数必须以某种方式被发现吗？我无法找到任何能让我清楚的事情.

如果没有,我进一步假设参数需要以其他方式记录,从而锁定(当前api的一部分),据我所知,这是不可取的,因为资源应该通过跟随超文本链接找到比硬编码位置(和这种情况下的参数).

假设参数必须是可发现的,有没有办法在tastypie/django中这样做？

Answer 1

REST 的“可发现”部分通常是指服务器返回的以前不存在的新资源（由 URI 表示）。然后，客户端应用程序可以选择在闲暇时与这些资源进行交互。

例如，我的应用程序可能返回GET一个/libraryURI，它返回我的本地库中内容的表示。返回的数据（编码为特定的基于 JSON 的媒体类型）可能如下所示：

{
   "printedBooks" : "/library/books",
   "audioTapes" : "/library/tapes"
}

现在让我们说几个月后我在同GET一个 URI 上做同样的事情，我现在可能会返回这个有效负载：

{
   "printedBooks" : "/library/books",
   "audioTapes" : "/library/tapes",
   "magazines" : "/library/magazines"
}

现在有一个指向magazines资源的新链接，我大概可以通过该链接GET找到可用的杂志类型。如果我的客户端应用程序不关心它，没什么大不了的 - 它只是像以前一样继续使用其他两个资源。在未来的某个时候，我也可能会编写对杂志搜索的支持。

但是，如果我编写了某种能够自动适应这种新资源的存在的超级动态奇特客户端应用程序，那么该应用程序的用户就可以毫不费力地使用它。无需升级：服务器提供了新功能，客户端充分利用了它。Web 浏览器以这种方式工作（尽管人类驱动了很大一部分“动态”）。

关于参数的具体问题：这些通常被指定为服务器 API 文档的一部分。我不知道有任何 API 以自动方式指定参数语法，允许客户端 100% 通用和适应性强。

定义良好的 RESTful API 站在它使用的已指定技术（HTTP、URI、内容类型协商、标头等）的肩膀上，并利用而不是重新定义它们。这就是为什么我知道我可能可以GET对/library/magazinesURI执行 a并请求基于 JSON 的编码，而且我很可能会成功。我知道如果我有特定杂志的 URI（例如，/library/magazines/1234），那么我可以尝试通过调用DELETE它来删除它，并且我会根据返回的 HTTP 状态代码知道它是否成功。我不需要阅读任何文档或使用任何编码魔法来完成任何这些事情，因为这些操作已经在 HTTP 中指定。

但是，要通过 POST 来创建新杂志/library/magazines，我需要知道我的参数数据的表示形式应该是什么样的，无论我是在 URI 内还是在 POST 正文内传递这些参数。这是需要在 API 文档中指定带外的数据。

因此，总而言之：RESTful 服务器可以向客户端发回他们以前没有看到的新信息，这是 REST 中可发现性的核心。但是当客户端想要向服务器发送数据时，它需要发送服务器能够理解和接受的数据，这通常在文档中描述。