RAML- !include 奇怪的行为

Posted

技术标签:

【中文标题】RAML- !include 奇怪的行为【英文标题】:RAML- !include strange behavior 【发布时间】:2017-07-12 20:52:50 【问题描述】:

我使用 Atom 的 this 扩展来设计我的 API,用 RAML 编写。

我想我这里有问题:(我掩盖了标题和 baseUri,抱歉):

如果我遵循 RAML 1.0 规范,我应该添加一个“!include”。奇怪的是,apiworkbench 没有检测到错误。

如果我这样做:

为什么这不起作用?

【问题讨论】:

【参考方案1】:

不,对于库,您不得使用 include 关键字。

似乎规范对此不是很清楚,或者至少我在任何地方都找不到明确的规定。因此,提出一个关于此的问题将是一个好主意。

但是,如果您检查规范中的 examples,您会发现在使用库时(带有“uses”关键字),“!include”被省略了。

【讨论】:

raml.org 上的示例用 !include 清楚地显示了它...当我阅读规范时,对此还不清楚.. 示例使用 !include 表示类型、特征、资源类型等,但在使用“uses”关键字时不使用,在这些示例中您会看到“!include”被省略。 【参考方案2】:

非常好的对话。实际上,规范应该对此更清楚,但是库遵循与普通!include 不同的方法的原因是,包含只是将新节点添加到您使用!include 关键字的现有节点。由于它确实是一个简单的“添加”操作,因此它不会掩盖任何循环依赖。

库非常不同,命名空间 (uses) 的使用也非常不同。库的目的是创建一个公共的可共享的资产/最佳实践定义组,人们也可以使用这些资产/定义在上面创建自己的库或其他定义。循环依赖是不可避免的。为此,RAML 工作组必须提出与!include 不同的机制。因此,对于您应该始终使用的库:

uses
  lib: mylib.raml

希望能解释其背后的合理性,但如果您有更多问题,请告诉我。

【讨论】:

以上是关于RAML- !include 奇怪的行为的主要内容,如果未能解决你的问题,请参考以下文章

直接在 swscanf 中使用 CString 的奇怪行为

C ++ Boost多线程奇怪的行为

奇怪的 mktime() 行为

地图中 upper_bound() 的奇怪行为

包装 abort() 系统调用时的奇怪行为

std::vector<QString,int*> 的奇怪行为