关于REST的几个问题

比方说，我有一篇文章资源，由作者编写。

基本上我会是这样的：

{ 
    "article": { 
     "id": 1, 
     "title": "Foo bar", 
     "body": "Lorem ipsum dolor sid amet", 
     "published_on": "2011-05-06 21:54:23", 
     "author": { 
      "id": 25, 
      "username": "johndoe" 
     } 
    } 
}

我会在api/articles/1

我的问题是访问我的资源，什么是代表这个数据的最佳方式？

我应该做的事情，如：

{ 
    "article": { 
     "id": 1, 
     "title": "Foo bar", 
     "body": "Lorem ipsum dolor sid amet", 
     "published_on": "2011-05-06 21:54:23", 
    } 
}

并获得笔者致电api/articles/1/author

只包含作者的ID（子对象标识符）

{ 
    "article": { 
     "id": 1, 
     "title": "Foo bar", 
     "body": "Lorem ipsum dolor sid amet", 
     "published_on": "2011-05-06 21:54:23", 
     "author": { 
      "id": 25, 
     } 
    } 
}

或包含如上看到的全关系？

2）PUT或POST创建新对象？

看到SO和其他地方，我注意到，两者都用于创建和/或更新对象。

据我了解，两者都是有效的行动，但它取决于上下文。如果我创建一个与之前创建的对象相关的子对象，我必须使用POST。

例如：我创建了一篇文章投票，因为文章已经存在，我会POST一个新的投票，但是，如果我创建一个新的文章，我PUT它。

我对不对？

3）我们应该如何格式化日期？

我见过使用Unix时间戳，其中ISO8601主要用于别处。

有没有关于此标准的任何“标准”或建议？

来源

2012-07-11 Trent

1）如何使用关系？

你的第一种方法不是很好，因为它不允许发现作者 - 可能是你想知道的东西。

第二种方法是有效的，但要求您事先知道URI模式以延迟获取作者，例如， api/author/25。

只要您没有一对多关系（文档大小按指数规律增长）或非常大的嵌套对象，第三种方法就没有问题。

由几个人主张的fourht方法是通过使用超链接而不是抽象标识符或完整文档来采用hateos原则。

2）PUT或POST创建新对象？

这里没有混淆。 POST总是用来创建新的对象，而PUT应该更新现有的（或者可能创建一个，如果它不存在的话）。底线：每次调用POST时，都会改变系统状态（资源）。 PUT多次（幂等性 - 当你想安全地重试时很好）

请注意，POST链接通常不包含ID（例如POST api/articles），而PUT DO：PUT api/articles/42如果知道ID，实体可能已经存在。

3）我们应该如何格式化日期？

UNIX时间戳和iso8601都没问题。我不知道是否有任何标准appart从JSON schema recommendations：

5.23。格式

[...]

date-time这应该是YYYY-MM-DDTHH的ISO 8601格式的日期：MM：SSZ以UTC时间。这是日期/ 时间戳的推荐形式。

来源

2012-07-11 12:34:28

关于REST的几个问题

回答

相关问题