我对REST感到困惑。我有一个服务,将json转换为excel文件。这是一项服务,并不代表一个实体,因此没有任何国家。
使用HTTP GET为此创建REST服务是否可以,或者将此类服务添加到我们的restful服务集合中的最佳做法是什么?
...它不是GET POST或PUT,它不是资源而且没有状态。它只是一种方法,一种功能。所以这样的功能与REST范例相吻合,对吧?那么正确设计或实施的是什么以及如何实现呢?
答案 0 :(得分:1)
这听起来像是一个POST电话。您正在创建一个对象,在本例中为Excel文档。这里唯一的怪癖是服务器不保存它的实例。但是,这可能是未来的功能,如果您决定保存电子表格,API仍然有意义(尽管响应将需要包含Id或URL以返回到新创建的资源)
此阶段唯一的决定是决定端点的名称。如果这是一个可以从JSON对象创建任何类型的通用电子表格的服务,它可能类似于以下内容。
发布/ API /电子表格
在这种情况下进行GET调用是没有意义的,因为没有任何事先有人可以检索。 PUT没有意义,因为我们没有更新现有实体。
答案 1 :(得分:0)
如果您的服务中有一个返回电子表格的路径/端点,最合适的方法是GET
,因为您正在检索电子表格。
对于REST,如果电子表格是动态创建的,那么这并不重要。从协议的角度来看,excel文件代表了你的状态'并且客户端通常使用GET
检索表示。如果电子表格在提出请求之前作为物理文件存在,则客户不会知道并且不在乎。
从HTTP角度来看,POST
并不是完全错误的,但如果您遵循REST最佳做法,那就不正确了。
然而:既然你说你正在改变'一个JSON对象,问题是...... JSON对象在哪里生存。是客户端发送它,还是已经在服务器上。
如果客户端正在提交JSON,然后服务器将其转换为excel,那么您需要一个两步的过程:
POST
,则可以使用Location
标头指示资源的创建位置。GET
请求,该请求具有Accept
标头,用于excel mime-type。如果您不想要2个请求,我认为没有合适的REST方式来执行此操作,您可能希望回退到一个POST请求并接受它并且#39;不是RESTful。
但是,我发现有些人使用Prefer: return=representation
标头将POST和GET请求合并为一个步骤。