gpt4 book ai didi

rest - 模拟HTTP上的过程调用的最佳/最RESTful方法是什么?

转载 作者:行者123 更新时间:2023-12-01 06:07:03 25 4
gpt4 key购买 nike

我有一个服务,需要一个.odt模板文件和一些文本值,并在输出时生成一个.odt。我需要通过HTTP使此服务可用,但我不太了解使接口正常工作的最RESTful方法是什么。

我需要能够将模板文件和输入值提供给服务器-并将生成的.odt文件发送回给我。我看到的工作方式如下:


将模板放置或发布到服务器,然后执行GET请求,并传递我刚发布的模板的URI,再加上输入值-GET响应主体将带有.odt
在单个GET请求中发送模板和参数-模板文件将放在GET请求主体中。
像上面的(2)一样,除了将整个事情作为单个POST请求而不是GET进行。


(1)的问题是我不想将模板文件存储在服务器上。这增加了复杂性,并且存储文件对我而言无济于事,因为它是一种非常RESTful的方法。同样,在其他所有条件相同的情况下,单个请求要比2好。

(2)的问题在于,将主体放入GET请求与滥用HTTP接壤-我正在使用的软件支持它,但可能并非总是如此。

数字(3)似乎具有误导性,因为这更自然地是“读取”或“获取”操作而不是“发布”操作。

我正在做的事情本质上就像一个函数调用-我需要传递大量数据,而实际上我只是在使用HTTP作为在网络上公开我的代码的便捷方式。也许我想做的是天生就没有REST风格,并且没有REST友好的解决方案?有人可以建议吗?谢谢!

最佳答案

哇,所以这个答案很快就升级了...

在过去的一年左右的时间里,我试图通过书籍,邮件列表等对REST进行更好的理解。出于某种原因,我决定选择您的问题作为对我所学知识的检验。

抱歉:P



让我们将整个示例简化一个步骤。不必担心用户上传文件,而是假设用户只是传递了一个字符串。因此,实际上,除了要替换的字符参数(键/值列表)之外,它们还将传递字符串。稍后我们将处理文件上传部分。

这是一种RESTful方式,不需要在服务器上存储任何内容。我将使用一些HTML(尽管损坏,但我将省略诸如HEAD之类的东西)作为我的媒体类型,只是因为它是众所周知的。

样品溶液

首先,用户将需要访问我们的REST服务。

GET /

<body>
<a rel="http://example.com/rels/arguments" href="/arguments">
Start Building Arguments
</a>
</body>


基本上,这为用户提供了一种开始与我们的服务进行实际交互的方式。现在,它们只有一个选项:使用链接构建一组新的参数(将在字符串替换方案中最终使用的名称/值对)。因此,用户转到该链接。

GET /参数

<body>
<a rel="self" href="/arguments"/>
<form rel="http://example.com/rels/arguments" method="get" action="/arguments?{key}={value}">
<input id="key" name="key" type="text"/>
<input id="value" name="value" type="text"/>
</form>
<form rel="http://example.com/rels/processed_string" action="/processed_string/{input_string}">
<input id="input_string" name="input_string" />
</form>
</body>


这将我们带到“参数”资源的实例。注意,这不是一个JSON或XML文档,它仅向您返回键/值对的纯数据;这是超媒体。它包含将用户引导到下一步操作的控件(有时称为允许用户“跟随他们的鼻子”)。此特定的URL(“ /参数”)代表键/值配对的空列表。如果可以的话,我很可能将URL命名为“ / empty_arguments”:这是一个为什么以URL来考虑REST却很愚蠢的例子:URL到底是什么并不重要。

在此新的HTML中,为用户提供了三种不同的资源,他们可以导航到这些资源:


他们可以使用指向“自己”的链接来导航到当前使用的相同资源。
他们可以使用第一种形式导航到一个新资源,该资源代表一个参数列表,并带有在表单中指定的其他名称/值对。
他们可以使用第二种形式提供希望最终替换的字符串。


注意:您可能已经注意到,第二种形式具有一个奇怪的“操作” URL:

/arguments?{key}={value}

在这里,我作弊:我正在使用 URI Templates。这使我可以指定如何将参数放置在URL上,而不是使用仅使用 <input-name>=<input-value>的默认HTML方案。显然,要使其正常工作,用户不能使用浏览器(因为浏览器未实现此功能):他们将需要使用能够理解HTML和URI模板的软件。当然,我以HTML为例,您的REST服务可以使用某种支持URI模板规范所定义的URI模板化的XML。

无论如何,假设用户要添加其参数。用户使用第一种形式(例如,用“作者”填写“键”输入,用“约翰·多伊”填写“值”)。这导致...

GET / arguments?Author = John%20Doe

<body>
<a rel="self" href="/arguments?Author=John%20Doe"/>
<form rel="http://example.com/rels/arguments" method="get" action="/arguments?Author=John%20Doe&{key}={value}">
<input id="key" name="key" type="text"/>
<input id="value" name="value" type="text"/>
</form>
<form rel="http://example.com/rels/processed_string" action="/processed_string/{input_string}?Author=John%20Doe">
<input id="input_string" name="input_string" />
</form>
</body>


现在,这是一种全新的资源。您可以将其描述为带有单个键/值对的参数列表(键/值对):“作者” /“约翰·多伊”。 HTML与以前几乎相同,但有一些更改:


现在,“自我”链接指向当前资源URL(从“ / arguments”更改为“ / arguments?Author = John%20Doe”
现在,第一种形式的“ action”属性具有更长的URL,但是我们再次使用URI模板来构建更大的URI。
第二种形式


用户现在想要添加“日期”参数,因此他们再次提交了第一个表单,这次的键为“日期”,值为“ 2003-01-02”。

GET / arguments?Author = John%20Doe&Date = 2003-01-02

<body>
<a rel="self" href="/arguments?Author=John%20Doe&Date=2003-01-02"/>
<form rel="http://example.com/rels/arguments" method="get" action="/arguments?Author=John%20Doe&Date=2003-01-02&{key}={value}">
<input id="key" name="key" type="text"/>
<input id="value" name="value" type="text"/>
</form>
<form rel="http://example.com/rels/processed_string" action="/processed_string/{input_string}?Author=John%20Doe">
<input id="input_string" name="input_string" />
</form>
</body>


最终,用户准备处理他们的字符串,因此他们使用第二种形式并填写“ input_string”变量。这再次使用URI模板,从而将用户带到下一个资源。假设该字符串如下:

{Author} wrote some books in {Date}

结果将是:

GET / processed_string /%7BAuthor%7D + wrote + some + books + in +%7BDate%7D?Author = John%20Doe&Date = 2003-01-02

<body>
<a rel="self" href="/processed_string/%7BAuthor%7D+wrote+some+books+in+%7BDate%7D?Author=John%20Doe&Date=2003-01-02">
<span class="results">John Doe wrote some books in 2003-01-02</span>
</body>


EW!要做很多工作!但这是(AFAIC)RESTful,并且满足了不需要在服务器端实际存储任何内容的要求(包括参数列表或最终要处理的字符串)。

重要注意事项

在此重要的一件事是,我不仅在谈论URL。实际上,大多数时候,我在谈论HTML。 HTML是超媒体,它是REST中被遗忘的重要部分。所有那些说“非常紧张”的API都说“使用这些参数在此URL上执行GET,并使用看起来像这样的文档在此URL上进行POST”,这些都没有在实践REST。罗伊·菲尔丁(Roy Fielding)(字面上是 wrote the book on RESTmade this observation himself

要注意的另一件事是,仅设置参数会很麻烦。在初始GET /之后,进入服务的根目录(您可以将其视为“菜单”),您将需要再执行五个GET调用,以建立您的参数资源以使参数资源为四个键/值配对。不使用HTML可以缓解这种情况。例如,我已经在示例中使用了URI模板,没有理由说HTML不足以支持REST。使用支持类似于表单但具有指定值“映射”功能的超媒体格式(例如XML的某种派生),您可以一次完成此操作。例如,我们可以扩展HTML媒体类型以允许另一种称为“映射”的输入类型...





只要使用我们的API的客户端了解什么是“映射”输入类型,他们就可以使用单个GET构建其参数资源。

那时,您甚至可能不需要“参数”资源。您可以直接跳到包含映射和实际字符串的“ processed_string”资源...






文件上传呢?

好的,所以最初您提到文件上传,以及如何在不需要存储文件的情况下进行上传。好吧,基本上,我们可以使用现有示例,但是将最后一步替换为文件。






在这里,除了上传文件外,我们基本上与以前做相同的事情。重要的是要注意的是,现在我们在提示用户(通过表单上的“ method”属性),他们应该执行POST而不是GET。请注意,即使到处都听到POST是不安全的(它可能导致服务器上的更改),非幂等操作,但并没有说必须在服务器上更改状态。

最后,服务器可以返回新文件(甚至更好的方法是返回一些超媒体或LOCATION标头,并带有指向新文件的链接,但这需要存储)。

最后评论

这只是这个特定示例的一小部分。我希望您已获得某种见识,但我告诫您将其视为福音。我确定有些事情我说的并不是真正的“ REST”。我计划发布此问题并回答 REST-Discuss Mailing List,看看其他人对此有何评论。

我希望借此表达的一件事是,最简单的解决方案可能就是使用RPC。毕竟,您最初使它成为RESTful尝试的尝试是什么?如果您想告诉别人您完成了“ REST”,请记住,很多API都声称自己是“ RESTful”,而这些API实际上只是被带有名词而非动词的URL伪装成RPC。

如果是因为您已经听说过REST的一些好处,以及如何通过使您的API RESTful隐式地获得这些好处,那么不幸的事实是REST的意义不仅仅在于URL,无论是GET还是POST到URL。超媒体扮演着重要的角色。

最后,有时您会遇到问题,这意味着您可能会执行SEEM非RESTful的操作。也许您需要执行POST而不是GET,因为URI(理论上有无限的存储空间,但有很多技术限制)会变得太长。那么,您需要执行POST。也许

更多资源:


REST-Discuss

My e-mail on this answer to REST-Discuss

RESTful Web Services Cookbook
Hypermedia APIs with HTML5 and Node(不是专门针对REST的,而是有关Hypermedia的非常好的介绍)

关于rest - 模拟HTTP上的过程调用的最佳/最RESTful方法是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9727394/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com