标签: hateoas

HATEOAS(超媒体作为应用程序状态的引擎)建议是否暗示查询字符串不是RESTful？

编辑:下面建议查询字符串可能与状态无关,因此问题令人费解.我建议除非客户端填充参数,否则URI有一个查询字符串是没有意义的.如果客户端正在填充参数,那么它正在掺杂服务器提供的URI,我想知道这是否违反了RESTful原则.

编辑2:我意识到如果客户端将其视为不透明(查询字符串可能是遗留的,因此方便),查询字符串似乎无害.然而,在下面的一个答案中引用Roy Fielding的话说,URI应该被认为是透明的.如果它是透明的,那么我相信鼓励掺假,这似乎淡化了HATEOAS原则.这种稀释是否仍然与HATEOAS一致？这引发了一个问题,即REST是否需要建立URI构建的紧密耦合.

更新在这个REST教程http://rest.elkstein.org/中,建议URI构建设计不好而且不是RESTful.它还在接受的答案中迭代@zoul所说的内容.

例如,"产品列表"请求可以返回每个产品的ID,并且规范说您应该使用http://www.acme.com/product/PRODUCT_ID来获取其他详细信息.这是糟糕的设计.相反,响应应包括每个项目的实际URL:http://www.acme.com/product/001263等.是的,这意味着输出更大.但这也意味着您可以根据需要轻松地将客户端定向到新的URL

如果一个人正在查看此列表并且不想要他/她可以看到的内容,则可能存在"前10个项目"和"下一个10个项目"按钮,但是,如果没有人,而是客户端程序REST的这个方面似乎有点奇怪,因为客户端程序可能没有用的所有" http:// www ".

我已经开始尝试使用Backbone.js,并对Backbone.Model上url属性的文档文档感到震惊.

特别是,我正在构建一个使用HATEOAS/hypermedia来驱动客户端的REST API.

我可以看到Backbone为集合中的项目构建URL本身的默认行为的有用性,但对于我的情况,我更倾向于使用已解析的数据构建模型URL.

有没有人在Backbone上扩展/构建它来做到这一点？也许建立在像HAL这样的"标准"上？

编辑:

为了澄清,让我说我有以下内容:

获取/订单>>

[
  {
     "_links": {
       "self": "/orders/123"
     }
     "name": "Order #123",
     "date": "2012/02/23"
  },
  {
     "_links": {
       "self": "/orders/6666"
     }
     "name": "Order #666",
     "date": "2012/03/01"
  },
]

我有一个订单模型,如:

var Order = Backbone.Model.extend({
});

我希望该url属性能够自动退出HAL中的"self"引用.我认为创建一个新的基础模型(未经测试):

var HalModel = Backbone.Model.extend({
  url: function() {
    return get("_links").self;
  },
});

思考？

我正在开发一个Angular 4前端,用于由另一个团队构建的API.API遵循HATEOAS并为我提供每个响应的超媒体链接.

我知道API的形状,我想我可以简单地将URL硬编码到Angular Services中.然而,一位同事(他是一名后端开发人员)试图说服我,我应该充分利用超媒体,因为它意味着前端和后端之间的耦合较少(如果API发生变化,可能会导致破坏).

但是,我对如何使用Angular的内置Http服务实现简单的HATEOAS模式感到困惑.如何以不将所有服务连接在一起并使其难以测试的方式存储/共享超媒体/ URL信息？似乎没有任何例子.

尝试创建一个HATEOAS友好的HTTP客户端甚至是一个好主意,还是可能不值得麻烦？

我最近和一个人说话,他们说他们正在完全跳过HATEOAS REST端点的开发,转而支持GraphQL.所以我很好奇为什么标准设置用于决定何时使用GraphQL与HATEOAS,或者GraphQL是一般的API网关/边缘服务器架构的更好选择？

据说,在一个定义良好的RESTful系统中,客户端只需要知道根URI或几个众所周知的URI,客户端就应该通过这些初始URI发现所有其他链接.我确实理解这种方法的好处(解耦客户端),但对我来说,缺点是客户端需要在每次尝试访问时发现链接,即给定以下资源层次结构:

/collection1
collection1
  |-sub1
    |-sub1sub1
 |-sub1sub1sub1
         |-sub1sub1sub1sub1
    |-sub1sub2
  |-sub2
    |-sub2sub1
    |-sub2sub2
  |-sub3
    |-sub3sub1
    |-sub3sub2

如果我们遵循" 客户端只需要知道根URI "的方法,那么客户端应该只知道上面的根URI即/ collection1,并且客户端应该通过超媒体链接发现其余的URI.我发现这很麻烦,因为每次客户端需要进行GET时,比如sub1sub1sub1sub1,如果客户端首先对/ collection1执行GET并在返回的表示中定义跟随链接,然后在子资源上执行几次GET以达到想要的资源？或者我对连通性的理解是完全错误的？

最好的问候,Suresh

我正在编写一个RESTful HATEOAS API.我有复合实体,我必须GET,POST和PUT.GET部分很简单,并且有很多例子.响应包含实体的原始属性以及指向嵌套实体的链接.例如:

{
 "id":"2",
 "firstName":"Brad",
 "lastName":"Pitt",
 "balance":1234.5,
 "transactions":"http://localhost:8080/jersey-poc/api/v1.1/account/1/transactions",
 "self":"http://localhost:8080/api/v1.1/account/1",
 "accountType":"http://localhost:8080/api/v1.1/account/1/accountType"
}

当我想创建或修改帐户时出现问题.我需要将帐户与accountType相关联.我可以发送一个POST请求,如下所示:{"firstName":"Michael","lastName":"Jackson","balance":300.0,"accountTypeId":5}
但这会破坏HATEOAS范例.POST/PUT复合实体的最佳做法是什么？

我见过HAL规范中描述的CURIEs .乍一看,它看起来像是一种为URI提供模板的方法.但是,我也看到它突出地提到它可以用来访问文档rel.哪一个？它只是一个模板机制吗？有没有人有一个好的用例的例子？

此外,以下是CURIE的合法使用吗？或者它应该只用于提供文件rel？

    { 
        "id": 1,
        "name": "Social Media Bundle",
        "_links": {
            "self": {
                "href": "http://my.api.com/bundles/1"
            },
            "curies": {
                "name": "bundle",
                "href": "http://my.api.com/bundles/1{rel}"
                "templated": true
            },
            "bundle:channels": {
                "href": "/channels"
            }
        }
    }

这里bundle:channels将扩展为http://my.api.com/bundles/1/channels.

我搜索了很多,但我找不到这个问题的好答案.作为一名HATEOAS爱好者,我认为这个标题非常适合:

    Range: item=1-20/100

在HTTP规范中,我不明白一些"矛盾":范围单位可以接受"其他范围单位"......

  range-unit       = bytes-unit | other-range-unit
  bytes-unit       = "bytes"
  other-range-unit = token

......但规范后来明确了:

HTTP/1.1定义的唯一范围单位是"字节".HTTP/1.1实现可以忽略使用其他单元指定的范围.

最后,该规范以此声明结束:

HTTP/1.1旨在允许实现不依赖于范围知识的应用程序.

• 是否允许除字节以外的任何其他单位
• 如果HTTP/1.1旨在允许应用程序不依赖于范围,那么依赖它来实现API的真正缺点是什么？

注意:我不关心"可浏览性".

我有许多使用Spring Boot构建的微服务,所以为了一点乐趣,我想我会为他们添加HATEOAS以帮助建立跨资源链接.它似乎在一个特定的项目中工作得很好,但我想知道是否有一种很好的方式来链接API.举个例子,假设我有3个服务:

用户详细信息服务:代码:

/users/{userid}

用户日历服务:代码:

/users/{userid}/appointments
/users/{userid}/appointments/{appointmentid}

用户消息服务:代码:

/users/{userid}/messages
/users/{userid}/messages/{messageid}

为了通过API实现这一点,最好是从用户资源到其约会和消息的链接.同样,从这些资源返回链接会很不错.当我有一个包含类路径上的所有内容的API时,这是非常可行的,我可以编写如下代码:

码:

user.add(linkTo(methodOn(CalendarController.class).appointments(user.getKey())).withRel("appointments"))

但是,如果CalendarController不在我正在服务的服务的类路径上,我就无法做到这一点.

有没有一个好的/推荐的方法来创建不在当前项目中的控制器的链接？

从春季论坛引用

我得出的结论是，构建一个真正的 RESTful API（使用 HATEOAS）几乎是不可能的。

我遇到的所有内容要么未能说明 HATEOAS 的真正威力，要么根本没有明确提及 HATEOAS 动态特性的固有痛点。

我相信 HATEOAS 的意义在于：

根据我的理解，真正的 HATEOAS API 应该拥有与 API 交互所需的所有信息，虽然这是可能的，但使用起来却是一场噩梦，尤其是在使用不同的堆栈时。

例如，考虑位于“/books”的资源集合：

{
  "items": [
    {
        "self": "/book/sdgr345",
        "id": "sdgr345",
        "name": "Building a RESTful API - The unspoken truth",
        "author": "Elad Chen ;)",
        "published": 1607606637049000
    }
  ],

  // This describes every field needed to create a new book
  // just like HyperText Markup Language (i.e. HTML) rendered on the server does with forms
  "create-form": {
    "href": "/books",
    "method": "POST",
    "rel": ["create-form"],
    "accept": ["application/x-www-form-urlencoded"], …