Question

给出以下类（注意：这些类没有讨论，它们就是这样存在的）

class Foo {}

class Bar {}

class Event {

  Foo foo;
  Bar bar;
  String event;

  public Event(Foo foo, String event){
    ..
  }

  public Event(Bar bar, String event){
     ..
  }
}

事件与Foo或Bar绑定，但从不与两者绑定。

您是否会为您的REST api建模（对您的api用户来说，或多或少感觉很自然）：

POST /foo/{FOO-ID}/event
GET /foo/{FOO-ID}/event  --> gets the list of events for FOO with the given id
GET /foo/{ID}/event/{EVENT-ID}

POST /bar/{BAR-ID}/event
GET /bar/{BAR-ID}/event --> gets the list of events for BAR with the given id
GET /bar/{BAR-ID}/event/{EVENT-ID}

或者您更喜欢（或多或少反映域模型）：

POST /event
GET /event?id=123&type=FOO --> gets the list events of for FOO with id = 123
GET /event?id=456&type=BAR --> gets the list of events for BAR with id = 456
GET /event/{EVENT-ID} 
GET /event --> not implemented, it would logically return ALL events(both FOO and BAR), but this has no business meaning

2个api中哪一个是'最'REST-ful？为什么？

Answer 1

从您的模型中，Event本身就是一个实体和资源。

第一种方法发送了不同的消息：从这个角度来看，Event是Foo或Bar的子资源，这意味着它取决于其中一个这些存在，如果它的“父母”不再存在，它也是如此。

现在我不认为你的模型有这种关系。如果没有Event / Foo，Bar可能没有意义，但它确实有意义。明天，Event可能与其他新实体有关，因此Event依赖于它们，Event应该在它开始跟踪它们时发生变化，而不是相反。

最后，查询参数的使用对于算法资源是常见的，或者作为集合的“范围”过滤器，第二种情况。

如果Foo或Bar作为类具有Event类型的属性，则可以应用第一种方法。

两种方法都是“RESTFul”。粗略地说，REST是以正确的方式使用HTTP方法，并使用唯一的URI来识别唯一的资源。问题是第二种方法更好地将您的模型（及其关系）描述为一组资源。

REST-ful API应该与您的域模型密切相关吗？

1 个答案: