谷歌翻译 API v2 是 RESTful 架构吗?

发布于 2024-11-19 16:54:19 字数 418 浏览 5 评论 0原文

Google 翻译 API v2 是纯 GET 风格,它们在 https://www.googleapis.com/language/translate/v2 处只有一个网址(或一个资源),

因此基本上该工具的所有变体都会像这样调用 https://www.googleapis.com/language/translate/v2?parameters

他们声称该服务是 RESTful (http://code.google.com/apis/language/translate/v2/using_rest.html) 因为它基于简单的 GET url。

但严格来说它真的是RESTful架构吗?

因为基于简单 GET url 的服务并不等同于 RESTful,对吗?

Google translate API v2 is pure GET style and they only have one url (or one resource) at https://www.googleapis.com/language/translate/v2

so basically all variants of the tool will be called like this https://www.googleapis.com/language/translate/v2?parameters

They claim that service to be RESTful (http://code.google.com/apis/language/translate/v2/using_rest.html) because it is based on a simple GET url.

But strictly speaking is it actually a RESTful architecture?

Because having a service based on a simple GET url is not analogous to being RESTful right?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

Spring初心 2024-11-26 16:54:19

仅当我可以将服务建模为面向资源(在大多数情况下是将数据公开为资源)时,我个人才会将任何服务公开为 REST。就 google 翻译 API 而言,它给人更多的 RPC 感觉,而不是它所公开的资源。
因此,即使 google 可能将其称为基于 REST(因为它基于简单的 GET URL),我也不会将其视为基于 REST 的服务。此外,如果您查看 URL,它不会识别资源,而看起来更像是一个端点,您可以将查询字符串中的值传递到该端点,并根据这些值获得结果。

I personally will expose any service as REST only if I can model the service as resource oriented which in most cases is about exposing data as resources. In case of google translate API, it gives more of an RPC feel rather than a resource that it is exposing.
Hence even though google may call it REST based (as it is based on simple GET URL), I would not consider it as a REST based service. Also if you look at the URL, it is not identifying a resource, rather it looks more like a endpoint to which you pass values in query string and based on those values you get the result.

疯狂的代价 2024-11-26 16:54:19

如果你想称之为 RESTful,它应该满足 Fielding 的标准

  • 客户端-服务器 - 将 UI 与数据存储分开

  • 无状态服务器 - 提高可靠性和可扩展性

    >

  • 客户端缓存 — 减少一些网络流量

  • 统一接口 — 将实现与其提供的服务解耦

  • 分层系统 - 意味着每个组件只关心其下方或上方的组件

  • 代码点播 - 允许通过下载小程序或脚本来扩展客户端功能

此外,它还应该具有可寻址资源、表示方向,自我描述消息、无状态服务器和可缓存性。

那么如果 API 只是一个带有多个参数的 GET 调用呢?问题是:GET(带参数)是否幂等且安全?嗯,我想是的。这是一个“只读”界面。您永远不会更改服务器上的状态。因此,对于给定的查询参数,GET 是安全的、幂等的且可缓存的。

这对我来说很宁静。

现在,当人们使用 GET 来发布内容时......那就是你应该反对的地方。

If you want to call it RESTful it should meet Fielding's criteria

  • Client-Server — separates UI from data storage

  • Stateless Server — improves reliability and scalability

  • Client Cache — reduces some network traffic

  • Uniform Interface — decouples implementations from the services they provide

  • Layered System — means that each component only be concerned with those just below or just above it

  • Code-on-Demand — allows client functionality to be extended by downloading applets or scripts

Also it should have addressable resources, representation orientation, self-descriptive messages, stateless server, and cacheability.

So what if API is just a GET call with multiple parameters? The question is: Is the GET (with parameters) idempotent and safe? Well I think so. It's a "read-only" interface. You never change the state on the server. So the GET is safe and idempotent and cacheable for given query params.

That is RESTful to me.

Now when people use GET to post stuff.... that's where you should object.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文