rest - ALPS示例实现

我正在寻找使用ALPS的示例客户端实现（不是山脉，而是应用程序级配置文件语义）。

你呢！有一个？

我已经研究了相关的RFC draft和讨论，但仍然可以弄清楚。

具体来说，我想知道我的客户应该如何了解描述符所描述的内容，因为我的客户应该对REST原理要求的REST API的结构和语义一无所知？

作为人类，我知道带有id标记的描述符称为“用户”，它可能描述如何与用户交互，但是在没有我明确告诉他的情况下，我的客户怎么知道？

我知道我可以插入某种关键字以显示在描述符中，并告诉我的客户匹配适当的关键字，但这似乎不是正确的方法。

鉴于有人愿意阅读，我很高兴提供一个更详细的示例。

最佳答案

我也是第一次探索ALPS，对RFC草案的理解也不是立即的。

这是RFC作者的slideshow (166 slides, so it's not possible to copy it all into this answer)，我认为可以更好地理解ALPS的作用。


作为一个人类，我知道带有descriptor标签的id称为users的可能描述了如何与用户交互，但是我的客户如何在不明确告诉他的情况下知道这一点？


从这张幻灯片中，我推断出您的问题的答案：他没有。

在幻灯片中，将示例ALPS配置文件与等效HTML代码进行表单提交进行比较。浏览器知道如何将HTML呈现到屏幕上，但是只有人类知道使用该提交按钮使用这些输入字段对表单进行POST的含义。

这是取自alps.io的示例完整JSON表示形式

{
  "alps" : {
    "version" : "1.0",
    "doc" : {
      "href" : "http://example.org/samples/full/doc.html"
    },
    "descriptor" : [
      {
        "id" : "search",
        "type" : "safe",
        "doc" : {"value" :
          "A search form with a two inputs"
        },
        "descriptor" : [
          {
            "id" : "value",
            "name" : "search",
            "type" : "descriptor",
            "doc" : { "value" : "input for search" }
          },
          { "href" : "#resultType" }
        ]
      },
      {
        "id" : "resultType",
        "type" : "descriptor",
        "description" : {"value" : "results format"},
        "ext" : [
          {
            "href" : "http://alps.io/ext/range",
            "value" : "summary,detail"
          }
        ]
      }
    ]
  }
}

例如，一个通用的移动电话应用程序正在基于REST响应向用户显示屏幕。假设HAL+Json响应包含对搜索实体的引用。该应用程序可以在此ALPS文档中查找搜索实体是什么，并且可以编码以表示该实体。即，搜索是具有name/value对（具有ID）和href的事物。 href引用ID为resultType的第二个descriptor，它使应用程序知道期望搜索结果的格式。涉及的实际URL和数据将来自REST响应。



从2014年7月开始，这里的Spring blog article描述了管理“待办事项列表”的应用的ALPS。 ALPS文件描述


什么是待办事项实体
待办事项实体可以执行哪些操作


该小型应用程序的ALPS配置文件的简化版本：

{
  "version" : "1.0",
  "descriptors" : [ {
    "id" : "todo-representation",
    "descriptors" : [ {
      "name" : "description",
      "doc" : {
        "value" : "Details about the TODO item",
        "format" : "TEXT"
      },
      "type" : "SEMANTIC"
    }, {
      "name" : "title",
      "doc" : {
        "value" : "Title for the TODO item",
        "format" : "TEXT"
      },
      "type" : "SEMANTIC"
    }, {
      "name" : "id",
      "type" : "SEMANTIC"
    }, {
      "name" : "completed",
      "doc" : {
        "value" : "Is it completed?",
        "format" : "TEXT"
      },
      "type" : "SEMANTIC"
    } ]
  }, {
    "id" : "create-todos",
    "name" : "todos",
    "type" : "UNSAFE",
    "rt" : "#todo-representation"
  }, {
    "id" : "get-todos",
    "name" : "todos",
    "type" : "SAFE",
    "rt" : "#todo-representation"
  }, {
    "id" : "delete-todo",
    "name" : "todo",
    "type" : "IDEMPOTENT",
    "rt" : "#todo-representation"
  } ]
}

我想有一种方法可以将其视为一种“模式”，但是它不是描述数据库表，而是描述REST响应的范围。