我对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文件代表了你的状态＆＃39;并且客户端通常使用GET检索表示。如果电子表格在提出请求之前作为物理文件存在，则客户不会知道并且不在乎。
从HTTP角度来看，POST并不是完全错误的，但如果您遵循REST最佳做法，那就不正确了。
然而：既然你说你正在改变＆＃39;一个JSON对象，问题是...... JSON对象在哪里生存。是客户端发送它，还是已经在服务器上。
如果客户端正在提交JSON，然后服务器将其转换为excel，那么您需要一个两步的过程：
POST，则可以使用Location标头指示资源的创建位置。GET请求，该请求具有Accept标头，用于excel mime-type。如果您不想要2个请求，我认为没有合适的REST方式来执行此操作，您可能希望回退到一个POST请求并接受它并且＃39;不是RESTful。
但是，我发现有些人使用Prefer: return=representation标头将POST和GET请求合并为一个步骤。