休息服务与基本功能

时间:2018-02-10 07:49:53

标签: rest

我对REST感到困惑。我有一个服务,将json转换为excel文件。这是一项服务,并不代表一个实体,因此没有任何国家。

使用HTTP GET为此创建REST服务是否可以,或者将此类服务添加到我们的restful服务集合中的最佳做法是什么?

...它不是GET POST或PUT,它不是资源而且没有状态。它只是一种方法,一种功能。所以这样的功能与REST范例相吻合,对吧?那么正确设计或实施的是什么以及如何实现呢?

2 个答案:

答案 0 :(得分:1)

这听起来像是一个POST电话。您正在创建一个对象,在本例中为Excel文档。这里唯一的怪癖是服务器不保存它的实例。但是,这可能是未来的功能,如果您决定保存电子表格,API仍然有意义(尽管响应将需要包含Id或URL以返回到新创建的资源)

此阶段唯一的决定是决定端点的名称。如果这是一个可以从JSON对象创建任何类型的通用电子表格的服务,它可能类似于以下内容。

发布/ API /电子表格

在这种情况下进行GET调用是没有意义的,因为没有任何事先有人可以检索。 PUT没有意义,因为我们没有更新现有实体。

答案 1 :(得分:0)

如果您的服务中有一个返回电子表格的路径/端点,最合适的方法是GET,因为您正在检索电子表格。

对于REST,如果电子表格是动态创建的,那么这并不重要。从协议的角度来看,excel文件代表了你的状态'并且客户端通常使用GET检索表示。如果电子表格在提出请求之前作为物理文件存在,则客户不会知道并且不在乎。

从HTTP角度来看,POST并不是完全错误的,但如果您遵循REST最佳做法,那就不正确了。

然而:既然你说你正在改变'一个JSON对象,问题是...... JSON对象在哪里生存。是客户端发送它,还是已经在服务器上。

如果客户端正在提交JSON,然后服务器将其转换为excel,那么您需要一个两步的过程:

  • PUT或POST以创建包含.json的资源。如果您使用POST,则可以使用Location标头指示资源的创建位置。
  • 跟进了GET请求,该请求具有Accept标头,用于excel mime-type。

如果您不想要2个请求,我认为没有合适的REST方式来执行此操作,您可能希望回退到一个POST请求并接受它并且#39;不是RESTful。

但是,我发现有些人使用Prefer: return=representation标头将POST和GET请求合并为一个步骤。