我有一个提供买卖报价的休息界面。
首先创建报价,然后进行可能的编辑,最后发布。
现在我的问题。由于在休息时禁止使用附加动词,我如何描述要约的发布?
这是一个潜在的宁静工作流程
创造
编辑
发布
删除
您可以在报价发布之前或之后删除它。在这种情况下,您将拥有其中之一。
路径可能有点争议,但通常名词是可以接受的。
我更喜欢上面的路径(也有形容词),但你可以做类似/published-buy-offers
的事情,或者你可以取消形容词,并假设资源的表示具有表示提供的种类和状态的字段。然后路径可以很简单,例如/offers
.
由于在休息时禁止使用附加动词,我如何描述要约的发布?
你会怎么做一个网站?
您可能会从一个网页开始,其中包含大量关于优惠本身的信息。该页面可能包含指向可能有用的其他网页的链接。
但是网页的关键元素是表单;该表单将包含一堆字段,其中一些通过用户界面公开,因为它们旨在进行审查和编辑,而另一些则隐藏在视图之外。表单将通过单击按钮提交,其事件处理程序将读取表单(控件和元数据),并使用该信息以及标准化的处理规则来生成发送到服务器的 HTTP 请求.
换句话说,与您在 stackoverflow 上发布问题以及我发布此答案时发生的情况几乎相同。
REST-API 的诀窍是相同的想法,但采用机器可读的形式。换句话说,我们如何设计网页,以便在没有人的情况下可以理解它来解决歧义?
反过来,这意味着我们需要更多地投资于标准化我们的表示和我们的链接关系,以便机器可以学习识别其中的字段并做正确的事情。
使用远程创作习惯也是可行的(尽管在网络上不太常见)。初始机制基本相同:您按照链接关系查找所需的文档。
您编辑该文档的本地副本,然后请求服务器修改其本地文档副本以匹配您的。
在这两种情况下,我们正在做的是使用通用文档传输协议来移动信息。
这与我们过去在办公室处理纸张的方式非常相似:从文件柜中取出文件,将一些新信息放入文件中,然后将文件放回文件柜中。实际文档对您需要的任何信息进行编码,但文件、文件标签和文件柜都是通用的。
在网络上,我们不是移动纸片,而是通过网络复制位。但基本的成语没有改变。
我有一个提供买卖报价的休息界面。首先创建报价,然后进行可能的编辑,最后发布。
我如何描述要约的发布?
两种方式之一:您定义一个协议,可用于发现某种形式,完成该形式的信息,然后将其 POST 回 Web 服务器;或者您定义可用于发现某些文档的协议,然后将该文档的 PUT/PATCH 编辑返回到 Web 服务器。
API 的“资源”是用于导航这些协议的文档。