我一直在阅读有关为将向客户公开的REST服务设计API的最佳实践。例如，我们应该使用名词来命名所有公开的 URI。此外，动词应遵循 HTTP 命令的语义。例如，GET 请求不应修改资源，而应在此处使用 PUT 请求。我在一次采访中被问到这个问题，但无法令人满意地回答这个问题——我正在设计一个计算器，它提供以下函数，在两个操作数上加、乘、除、减。如何按照 REST 原则向客户端公开这些方法。用于这些操作的 URI 是什么？而且我不确定是否将添加操作映射到 GET、PUT 或 POST。 其他操作(除法、乘法等)也是如此。这里的指导方针是什么？
这里的准则是什么？
你会如何用网站做到这一点？
这应该是你第一次启发式的，每当有人问你关于REST的问题时。 REST是一种
架构风格，专为"跨越多个组织的基于网络的长期应用程序"而设计。 此体系结构样式的参考应用程序是万维网。
我正在设计一个计算器，它提供以下功能，在两个操作数上进行加、乘、除、减。如何按照 REST 原则向客户端公开这些方法。
客户端有三条信息，需要传达给服务器 - 操作和两个操作数。 一个是网络，收集这种信息的通常方法是提供表格。 在这种情况下，它可能是一个操作下拉列表，以及几个用于接受数字的文本控件。 因为纯函数是安全的，我们可能会使用GET作为 form 方法。 因此，HTML 处理规则将采用表单描述的值，并将它们转录为查询部分中的键值对。
所以网址看起来像
/22520c7f-6207-490e-99c9-bd1bb37f4056?op=add&firstArg=6&secondArg=9
关键的概括是要意识到HTML表单正在扮演URI模板的角色 - 服务器将模板传递给客户端，客户端填写详细信息并使用结果作为请求的目标。
这意味着，如果要将 HTML 替换为其他媒体类型，则需要指定 URI 模板的说明、描述可接受范围的一些机制以及哪些值可能是合理的默认值。
用于这些操作的 URI 是什么？
用休息？ 绝对不重要。 这是重点的一部分 - 客户端将URI视为不透明值。
URI只是标识符;你可以把它们想象成程序中的变量名称。 机器只是不在乎拼写是什么(只要这些拼写与RFC 3986一致)。
由于拼写无关紧要，因此您可以使用本地拼写约定中的任何内容。 很多人喜欢"可破解"的URI——标识符的拼写向人类读者传达了有用的信息。
URI是资源的标识符;"任何可以命名的信息都可以是资源"。 这激发了一些"名词不是动词"的噪音——资源是网页、文档、图像、脚本或......"资源"概念刻意含糊，以便灵活运用。
我不确定是将添加操作映射到 GET、PUT 还是 POST。
关键是查看客户端请求的语义。 任何时候你正在做的是查询/查找，机器可以为用户自动做一些事情，那么你正在查看安全语义，并且该方法可能是GET或HEAD(特殊情况)。
如果我们要求服务器更改其自身资源的表示形式，那么PUT和POST就会发挥作用。
在这种情况下，所有这些操作都只是在执行查找，因此GET是合适的。
(需要注意的一件有趣的事情是，这些操作都不依赖于服务器状态;它们是纯函数。 因此，为客户端提供code on demand- javascript或一些合理的替代品 - 并使用客户端的处理器来执行计算而不是在网络上进行一堆往返可能是有意义的)。
我认为术语REST的一个问题是它对不同的人有不同的含义。面试官可能对 REST 有不同的理解。当这样的事情出现时，我的第一个倾向是试图弄清楚REST对他们意味着什么。他们的意思是超媒体吗？他们是否关心您提到的动词和名词的正确使用？或者在他们心目中，REST只是一些返回JSON的HTTP端点。所有这些都是可能的。
我认为，我倾向于回答以下问题：
GET /add/1/2
GET /multiply/5/6
etc..
其他比我更有经验的人已经用一些好方法的例子来回答这个问题。
我只想指出这是一个非常好的问题。 我正在读理查德·泰勒(Richard Taylor)和加州大学欧文分校(UC Irvine)其他人的一篇论文。 理查德·泰勒(Richard Taylor)是罗伊·菲尔丁(Roy Fielding)的导师，当时菲尔丁在他的博士论文中描述了REST。 在比较 REST 和 SOAP 的讨论中，本文包括以下内容：
"...服务语义越接近内容语义，服务就越有可能拥有丰富的 REST API。
。
REST和SOAP之间的划分可能反映了缺乏设计指导;如何 不以内容为中心的服务，例如竞价竞价 ...以 REST 一致的方式干净地构建？
当他们说"更接近内容"时，他们的意思是服务看起来更像是最终用户检索的一些动态或静态信息，而不是服务看起来像是主动为用户执行某些功能或计算的东西。
他们继续提供这方面的额外指导 - 但我还没有读完论文，所以我会让你自己查找。 :-)
在网上搜索： 从表示到计算：的演变 Web Architectures， Richard N. Taylor， UCI