小编Ser*_*yuk的帖子

HATEOAS背后的核心思想之一是客户端应该能够从单一入口点URL开始,并发现所有可用的公开资源和状态转换.虽然我可以很好地看到它如何与HTML和人类在浏览器后面点击链接和"提交"按钮,我被问及这个原则如何应用于我(非)幸运地处理的问题.

我喜欢RESTful设计原则如何在论文和教育文章中呈现,这一切都有意义,如何获得一杯咖啡就是一个很好的例子.我将尝试遵循惯例,并提出一个简单且没有繁琐细节的例子.我们来看看邮政编码和城市.

问题1

假设我想设计RESTful api,用于通过邮政编码查找城市.我想出了嵌套在邮政编码中的称为"城市"的资源,因此GET on http://api.addressbook.com/zip_codes/02125/cities返回包含代表Dorchester和Boston的两条记录的文档.

我的问题是:如何通过HATEOAS发现这样的网址？暴露所有~40K邮政编码的索引可能是不切实际的http://api.addressbook.com/zip_codes.即使拥有40K项目索引并不是一个问题,请记住我已经制作了这个例子,并且有更大规模的集合.

基本上,我想要暴露不是链接,而是链接模板,而不是像这样:http://api.addressbook.com/zip_codes/{:zip_code}/cities,这违背了原则,依赖于客户拥有的带外知识.

问题2

假设我想通过某些过滤功能公开城市索引:

• GET on http://api.addressbook.com/cities?name=X将仅返回名称匹配的城市X.

• GET http://api.addressbook.com/cities?min_population=Y仅会返回人口相等或大于的城市Y.

当然这两个过滤器可以一起使用:http://api.addressbook.com/cities?name=X&min_population=Y.

在这里,我不仅要公开url,还要公开这两个可能的查询选项以及它们可以组合在一起的事实.如果没有客户端对这些过滤器的语义的带外知识以及将它们组合到动态URL中的原则,这似乎是根本不可能的.

那么HATEOAS背后的原则如何帮助制作这样简单的API真的是RESTful？

我们假设我们有以下实体:

• 制作工作室
• 记者
• 相机操作员
• 新闻镜头

在这个简单的世界中,制作工作室有许多记者和许多摄影师.每个记者都属于一个工作室.运营商也是如此.一个新闻记者和一个操作员制作新闻片段,两个来自同一个工作室.

这是我将这个模型放入关系数据库的天真方法:

CREATE TABLE production_studios(
  id                   SERIAL PRIMARY KEY,
  title                TEXT NOT NULL
);

CREATE TABLE journalists(
  id                   SERIAL PRIMARY KEY,
  name                 TEXT NOT NULL,
  prodution_studio_id  INTEGER NOT NULL REFERENCES production_studios
);

CREATE TABLE camera_operators(
  id                   SERIAL PRIMARY KEY,
  name                 TEXT NOT NULL,
  production_studio_id INTEGER NOT NULL REFERENCES production_studios
);

CREATE TABLE news_footages(
  id                   SERIAL PRIMARY KEY,
  description          TEXT NOT NULL,
  journalist_id        INTEGER NOT NULL REFERENCES journalists,
  camera_operator_id   INTEGER NOT NULL REFERENCES camera_operators
);

这个模式形成了形状很好的钻石ERD和一些问题. …