处理从网站到 API 提供商的 AJAX 请求的最佳实践

发布于 2024-10-14 16:24:25 字数 689 浏览 8 评论 0原文

因此,我实现了一个可供 Web 应用程序和移动应用程序访问的 API 提供程序。

这很可能不会是一个大型项目,但我想最大限度地利用我的学习经验并尽可能地探索。

无论如何,据我了解,似乎最好将 API 提供程序服务和实际网站放在不同的域中,以便更容易扩展。 例如,twitter 有网站 twitter.com 和 api.twitter.com。

一个迫在眉睫的问题是处理 AJAX 的跨域问题。 据我所知,有 2 种方法可以实现跨域 AJAX

  1. JSONP: 我听说过它,但除了代理服务器这个名称之外,了解不多
  2. :所以,我的网站是建立在 ASP.NET MVC 之上的,我是考虑创建一个 APIProxy 控制器来处理所有跨域 API 请求。

这样,我将通过 $.ajax(settings) 进行 AJAX 调用,然后传入与 APIProxy 控制器对应的网站 URL。然后,APIProxy 控制器将进行适当的 POST 服务器调用并处理 JSON 响应,并将响应返回到 AJAX 回调函数。

我听说 flXHR 说我不想使用 Flash,因为 iPad 或任何移动设备等设备浏览器不支持 Flash。

无论如何,我只是想问一下在单独的域或子域上使用 API 提供商管理网站的最佳实践是什么。

So, I implemented an API provider to be accessed by both web application and mobile applications.

Most likely this will not be a large scale project, but I want to maximize my learning experience and geek out where I can.

Anyway, from what I understand, it seems like it's better to put the API provider service and the actual website on separate domains to make scaling easier.
For example, twitter has the website twitter.com and api.twitter.com.

One immediate issue would be dealing with the cross-domain issue with AJAX.
From what I gather, there are 2 ways to implement cross-domain AJAX

  1. JSONP: I heard about it, but don't know much beyond the name
  2. Proxy Server: so, my website is build on top of ASP.NET MVC and I was thinking about creating a APIProxy controller to handle all cross-domain API requests.

That way, I would make an AJAX call via $.ajax(settings) and then pass in the website URL that corresponds to the APIProxy controller. The APIProxy controller would then make the appropriate POST server calls and process the JSON responses and return the response back to AJAX callback functions.

I heard about flXHR about I don't want to use Flash because devices like the iPad or any a lot of mobile browsers don't support Flash.

Anyway, I just wanted to ask what are some of the best practices in managing a website with the API provider on a separate domain or subdomain.

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

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

发布评论

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

评论(1

心意如水 2024-10-21 16:24:25

当您请求一些 JSON 时,它会返回一个对象或数组。脚本标签不受同域规则的约束。因此,您实际上需要执行以下操作,而不是进行 AJAX 调用:

<script src="Http://api.example.com?param1=something&etc"></script>

这将加载 JSON,并将作为 JavaScript 执行。

...但是一个简单的对象或数组本身“执行”并不是很有用。因此,当您请求 JSON 时,还需要包含回调函数的名称。如果提供者发现提供了回调,它实际上返回 JavaScript,而不是仅仅返回 JSON:JSON 作为参数传递给您的函数。

然后,当脚本加载时,您的函数(您已经定义的)将被调用,并给出要使用的 JSON。

这就是 JSONP。

参考书目

  1. 牛顿,亚伦。 “Request.JSONP。” 客户杀戮。 2009 年 12 月 7 日。网络。 2011 年 1 月 28 日。

When you request some JSON, it returns an object or array. Script tags are not subject to the same-domain rule. So instead making an AJAX call, you would essentially do this:

<script src="Http://api.example.com?param1=something&etc"></script>

That would load the JSON, and it would execute as JavaScript.

...But a simple object or array "executing" by itself isn't very useful. So when you request the JSON, you also include the name of a callback function. If the provider sees that a callback was provided, instead of just returning JSON, it actually returns JavaScript: the JSON is passed to your function as an argument.

Then, when the script loads, your function (which you already defined) is called, and given the JSON to work with.

That's JSONP.

Bibliography

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