如何创建 RESTful 计算器? [英] How can I create a RESTful calculator?

问题描述

鉴于 RESTful Web 服务都基于一切都表示为资源并且可以通过地址 (URI) 访问"的神圣思想，这对于 CRUD 应用程序可能有意义(所有示例都是关于列出/创建/更新/删除实体).但是，其他业务逻辑如何，例如，创建一个与 CRUD 操作无关的简单计算器 RESTful 服务?对于这样的 REST 服务来说，什么是好的设计?

Given that RESTful web services are all based around the sacred idea that "everything is represented as resources and can be accessed by an address (URI)", this may make sense for CRUD applications (all examples are about listing/creating/updating/deleting entities). However, how about other business logic like, for example, creating a simple calculator RESTful service that has nothing to do with CRUD operations? What can be a good design for such a REST service?

其次，如果 SOAP 的逻辑已经完全合理，那么使用 REST 而非 SOAP 的真正优势是什么?

Secondly, what is the real advantage of using REST over SOAP if the logic of SOAP already makes complete sense?

推荐答案

计算器服务很容易以 RESTful 方式建模.CRUD"中的R"代表读取"，读取"没有理由不能同时表示计算".因此，可以通过 GET 访问一个简单的反向波兰语计算器服务:

A calculator service would be simple to model in a RESTful manner. The "R" in "CRUD" stands for "read", and there's no reason that "read" can't also mean "compute". So a simple Reverse Polish calculator service could be accessed via GET:

GET https://calc.com/rpnCalc?3&4&%2B
7

上面的 URI 方案只是在 GET 请求中添加了三个参数:

The URI scheme above simply adds three parameters to the GET request:

3
4
+ (URL-encoded as %2B)

这是一个幂等、安全且可缓存的请求.如果这是一个非常复杂的数学查询，需要花费几分钟来计算，我可以将这些查询路由到一个开箱即用的 HTTP 代理，并在重复查询相同的 URI 时使用它立即返回任何预先计算的值.

That's an idempotent, safe and cacheable request. If this was an insanely complicated math query that took many minutes to compute I could route these queries to an out-of-the-box HTTP proxy and use it to instantly return any pre-computed values should the same URI be queried repeatedly.

根据您需要进行的计算类型，您还可以向计算器资源发布非常复杂的查询(将查询作为请求正文传递)，服务器可能会将 URI 返回到结果"资源，然后您可以 GET 来检索结果，甚至可以对它们进行分页.

Depending on the kinds of calculations you need to do, you could also POST a very complex query to a Calculator resource (passing in the query as the request body) and the server might return the URI to a "result" resource, which you can then GET to retrieve the results, and even paginate through them.

其次，使用 REST 而非 SOAP 的真正优势是什么?SOAP 的逻辑已经完全合理了吗?

Secondly, what is the real advantage of using REST over SOAP if the logic of SOAP already makes complete sense?

我可以使用诸如 curl 之类的命令行工具访问上述计算器服务，而无需构建复杂的肥皂.我可以在几秒钟内编写对它的调用，而无需使用任何第三方 XML 库或 SOAP 工具包.我可以使用诸如 HTTP 代理之类的商品工具来缓存结果并提高性能.我不必担心 SOAP 互操作性或检查 WS-I 兼容性.如果我正确使用超链接，那么我就可以改进和改进我的服务，而不会影响现有客户，甚至不需要重新编译.没有 WSDL 版本，也没有我必须维护多年的脆弱合同.客户端已经知道 GET/PUT/POST/DELETE 做什么，我不必重新定义或重新记录他们的语义.决定更喜欢 JSON 而不是 XML 的 API 客户端可以使用 HTTP 的内置内容协商功能来获取它.我可以使用 SOAP 和 Web 服务绝对零做这些事情.

I can access the above calculator service using a command-line tool like curl without building a complex piece of SOAP. I can code calls to it in seconds without having to use any third-party XML library or SOAP toolkit. I can use commodity tools like HTTP proxies to cache results and improve performance. I don't have to worry about SOAP interoperability or check for WS-I compatibility. If I use hyperlinks correctly then I can evolve and improve my service without affecting existing clients or having them to even recompile. There's no WSDL to version and no brittle contract which I have to maintain for years. The clients already know what GET/PUT/POST/DELETE do and I don't have to redefine or re-document their semantics. API clients that decide they'd prefer JSON instead of XML can get it using HTTP's inbuilt content-negotiation feature. I can do absolutely zero of these things with SOAP and Web Services.

嘿，如果 SOAP 满足您的需求，那就来吧.使用 REST 有很多好处，但它们可能不适合您的情况.至少，通过一本像样的书来了解 REST 能给你带来什么喜欢这个，然后在看完完整故事后下定决心.

Hey, if SOAP fits your needs, have at it. There are many benefits to using REST but they might not be appropriate to your situation. At the very least, learn about what REST can give you with a decent book like this one and then make your mind up after getting the full story.

这篇关于如何创建 RESTful 计算器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！