问题标签 [hypermedia]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
json - RAML API Designer 模拟服务:带有绝对 URL 的 HATEOAS 响应?
我使用 RAML 工具创建了 REST API 模拟。如何在我的 JSON 对象响应超媒体链接中返回绝对路径?
有没有办法将baseUri包含到我的示例 JSON 对象中以创建绝对路径?
现在我"/users/ff33c2a1-b877-4415-9e62-115b8239c787"
的 JSON 对象中有相对路径:
实际上我想要从我的baseUri值中获取根的绝对路径。
例如路径应该是这样的"http://mocksvc.mulesoft.com/mocks/a2683439-a5dc-409c-801a-c771042970fb/mocks/31e46658-b4ce-4f40-cc91-c4fd50f7a2d8/v1/users/ff33c2a1-b877-4415-9e62-115b8239c787"
我尝试使用类似的东西:
"href": "{baseUri}/users/ff33c2a1-b877-4415-9e62-115b8239c787"
或不带引号
"href": {baseUri}/users/ff33c2a1-b877-4415-9e62-115b8239c787
但以上都没有奏效。
我正在使用RAML 0.8。
rest - HATEOAS 和微服务
我在看到 HATEOAS 和微服务如何共存时遇到了一些严重的问题。
举个例子:
假设我们有一个购物车资源。并且我们需要将产品的快照放入其中,例如产品ID,产品价格;将商品添加到购物车时的当前价格快照,可能还有其他一些值。实际用例无关紧要,只是为了对手头的问题有所了解。
当我之前一直在做 HATEOAS 时,我会在购物车资源中放置一个链接到产品的链接或链接到特定产品的模板 url。
这样,客户端仍然可以不知道资源 URL。
但是在微服务世界中,一个服务不应该知道其他服务。AFAIK。
那么他们两个怎么可能一起工作呢?
我对微服务的解释是它们永远不能链接到除了它们自己之外的任何东西,这几乎就是一个Self
链接。
我在其他地方发现了同样的问题,例如 https://groups.google.com/forum/#!topic/api-craft/YRkLFVY_zFc
使用诸如“宏服务”之类的解决方案将所有这些结合在一起。这似乎不是解决问题的干净方法。
[编辑]
我发现了一些关于这个主题的更好的信息: https ://github.com/Netflix/eureka https://github.com/RestExpress/HyperExpress
有一些工具通过链接来增强资源似乎很好,但这让我想,决定资源应该属于哪些链接的逻辑在哪里?在暴露资源的服务中?在中央服务注册表中?
rest - 什么是超媒体,超媒体控件,超媒体格式
我目前正在阅读“实践中的休息”一书。我无法理解以下术语超媒体、超媒体格式、超媒体控件、域应用程序协议。作者建议需要特定领域的超媒体格式。我几乎无法理解那些。我用谷歌搜索了这些术语,但找不到正确的答案。谁能解释这些术语以及为什么我们需要特定领域的超媒体格式而不是 application/xml ?
angularjs - 超媒体 (HATEOAS) 驱动的 AngularJS 应用程序中的 URL 处理
我们正在寻找一些关于在由 HATEOAS REST API 支持的 Web 应用程序中处理 URL(以及与每个 URL 相关的状态)的建议,更具体地说,
- 如何避免将 Web 应用程序 URL 与 REST API URL 耦合
- 如何在单个视图中处理多个资源
但让我首先提供更多背景信息:
我们正在一个带有超媒体约束的 REST 层之上构建一个 Angular Web 应用程序。(注意:我更喜欢简单地使用术语“超媒体(约束)”而不是 HATEOAS)。
正如超媒体约束所规定的,应用程序中任何时间点的可用操作和链接都由 REST API 提供。因此,Web 应用程序不应包含 REST API 的任何硬编码 url,除了“根”(假设该概念确实存在于 REST API 中)。
另一方面,Web 应用程序中的每个页面都需要可添加书签。所以我们不能创建一个黑盒应用程序(在不更改 URL 的情况下在 SPA 中处理单个 URL 和所有状态更改)。这意味着 Web 应用程序也有它的 URL 空间,它需要以某种方式映射到 REST API URL 空间。这已经与超媒体理念相冲突。
在 Angular 应用程序中,我们使用 UI Router 来处理应用程序状态。这是我们如何让它工作的:
- 我们只定义状态,没有 URLS
- 我们定义了一个 $urlRouterProvider.otherwise 处理程序,它将当前 Web 应用程序 URL 映射到相应的 REST API URL,检索与该 REST URL 对应的资源表示并将其传递给控制器(在 $stateParams 中)。
- 然后控制器可以使用表示中的数据(以及链接和操作),就像它自己(或通过服务)进行 REST 调用一样
到目前为止这么好(或不是真的),因为这种方法有一些缺点:
- Web 应用程序 URL 映射到 REST API URL,因此两个 URL 空间是耦合的,这与使用超媒体约束的基本假设之一相冲突:我们不能在不更改 Web 应用程序的情况下更改 REST API URL。
- 在 $urlRouterProvider.otherwise 处理程序中,我们检索当前 Web 应用程序 URL 的表示。但在某些情况下,我们在单个视图中有两个资源(使用 UI Router 嵌套状态):例如项目列表和单个项目的详细信息。但是只有一个 URL,所以只检索项目详细信息的表示,项目列表保持为空。
因此,我们很想听听一些关于如何改进处理这两个 URL 空间的方法的建议。有没有更好的方法让 REST API 决定 Web 应用程序的(可用)行为,并且在 Web 应用程序中仍然有可收藏的 URL?因为现在我们有某种感觉并不完全正确的混合方法。
提前致谢。
问候,
卢克
rest - HATEOAS REST API 和领域驱动设计,工作流逻辑放在哪里?
这旨在作为 RESTful API 的后续问题:我应该在哪里编写我的工作流程?问题的简短摘要(适合我的问题更好一点)将是这样的:
每个域对象都包含与特定有界上下文 (X) 中的特定对象相关联的业务逻辑。REST API 包含将查询或命令的结果转换为通过网络发送的数据(例如 JSON)的逻辑。在使用 HATEOAS 和超媒体时,我们希望使用链接对资源之间的关系进行建模。但是为了确定 REST API 应该返回哪些链接,通常需要求助于业务逻辑/规则。问题是,这些“工作流程规则”在 DDD 应用程序中属于哪里?它们可能处于仅处理工作流规则的不同有界上下文中(可能与 X 处于类似“伙伴”的关系中)还是属于 X BC?
web-services - 使用第三个来协调两个 restful 服务的交互的最佳方法是什么?
我有 3 个安静的服务(ServiceA、ServiceB 和 ServiceC),它们处理 2 个资源(ResourceA 和 ResourceB)。资源的媒体类型为application/hal+json。
- ServiceA生成ResourceA;
- ServiceB消费ResourceA,产生ResourceB;
- ServiceC 通过从 ServiceA 获取 ResourceA 并将其发布到 ServiceB 来协调 ResourceB 的生产。
我基本上看到了两种组织这种互动的方法。
ServiceC 作为 ResourceA 直接中介
- ServiceC 从 ServiceA 获取完整的 ResourceA
- ServiceC 将其发布到 ServiceB
- 服务 B 返回资源 B
ServiceC 作为 ResourceA 间接中介
- ServiceC 仅在 ServiceA 上获取到 ResourceA 的链接(例如,通过 ResourceA 创建时的 Content Location 标头)
- ServiceC 将此链接发布到 ServiceB(使用 HAL 媒体类型的链接 rel)
- ServiceB 直接从 ServiceA 获取完整的 ResourceA
- 服务 B 返回资源 B
第一种方法似乎是“经典”方法,而第二种方法会更便宜,因为只有一个完整的 ResourceA 传输(ServiceA -> ServiceB)而不是两个(ServiceA -> ServiceC -> ServiceB)。理想情况下,对于足够大的 ResourceA,第二种方法会更好。
使用第二种方法有什么问题吗?这被认为是“反模式”还是在某种程度上不安全/不值得推荐?有更好的交互模式吗?
rest - 如何在 REST Api 中表示只读属性
如果您有一个REST API
that is (HATEOAS),您可以通过在响应 ( )hypermedia-driven
中包含或省略链接来轻松更改客户的行为。_links
这使客户端能够完全忘记测试在当前状态下可能执行的操作的权限(操作resource
的链接是否存在)。
此外,如果当前用户无权查看它,您可以在响应中省略属性。
这样授权完全在服务器上完成(并控制有资格执行/查看的操作和属性)。
但是,如果我想拥有read-only
房产怎么办?REST
API
如果请求(_POST_
或_PUT_
)中存在该属性,则忽略该属性是没有问题的。它只是不会被保存。但是客户端如何区分写入和只读属性以向用户呈现适当的控件(如禁用的输入字段在HTML
)?
目标是永远不会拥有client request
用户的权限,而是拥有完全由资源驱动的client/frontend
.
任何帮助是极大的赞赏 :-)
web-services - 如何为组和列表形成超媒体
我正在设计一个 REST API,在这个特定的用例中,试图找出最好的方法以及这个超媒体应该是什么样子。
场景是呼叫者打电话/persons?fields=lastName;filter=beginsWith=b
是因为他想要返回一个姓氏以“b”开头的人的列表。
下面显示了我试图弄清楚如何最好地塑造/表示包括与之关联的超媒体的 JSON 响应。
您可以看到人员列表,而您只能看到 name 属性,因为它是每个人的部分表示。
然后我尝试在此处添加 HATEAOS,但不确定添加最有用的内容以及应该参考的内容。
我想好吧,我可以为我要返回的组(列表)本身提供一个 href。如果是这样的话,在哪里?我不认为像我正在做的那样把它放在根对象中是没有意义的。因为期望是返回一个人员列表,而不是一些根元对象,所以我对下面的内容感觉不好。
或者
有没有人认为在这个特定的实例中它没有用或没有真正接受 HATEOS,我应该在这里提供一些其他类型的 href 链接?
JSON - 返回的人员对象(表示)列表
json-ld - 关于 Hydra 条款的一些问题
我正在为 Golang 开发Hydra文档生成器。我一直以演示为例,我想知道一些 hydra 术语的歧义。
hydra:title
和有什么区别rdfs:label
?label
用于vocab:User
, 但hydra:title
用于Resource
andCollection
, 以及用于属性。- 说到
Resource
andCollection
,为什么在这个 ApiDocumentation 中重新描述了它们?它们不应该是 hydra/core 的一部分吗? - 在许多属性中,a
hydra:title + hydra:description
和label + description
that 都包含相同的信息。这是为什么?我可以忽略一个并且很好吗?
如果我未能在规范中发现这一点,请提前道歉,但我最近才对超媒体 API 产生了兴趣,而且许多概念仍然有点模糊。
rest - HATEOAS 与 PUT/POST 链接
POST
代表资源上//的PUT
HATEOAS链接的最佳方式是PATCH
什么?这些操作具有有效负载,但我们无法选择在 HATEOAS 链接中表示有效负载,因为它们不是预先确定的并且可能很重。那么仅指定终点并指定操作就足够了吗?
POST
对于带有 HATEOAS //链接的 JSON 响应,任何示例或示例将不胜感激PUT
。PATCH