JSONP与真实REST的关系

根据我的理解,JSONP只能通过GET动词实现。

对。

这就排除了真正的REST的核心遵从性,你应该使用不同的动词,比如GET、PUT、POST、DELETE等

我不太在意将REST作为一个抽象的标准来遵守,但是如果不正确的、可泄漏的、可缓存的GET请求可能会意外地产生副作用,这确实是一个令人担忧的问题。

JSONP非常有限,因为它包括使用 <script> 标记,然后对处理的某个函数进行回调。

JSONP是一种安全边界解决方法(ajax调用只允许在同一个域上进行)。如前所述,它非常有限,只能用于只读(HTTP GET through html script/src includes)。因此,它简化了集成和mashup,而不需要服务器端代理来发出真正的api HTTP请求。

但是我决不会仅仅为了让jsonp do执行任何写操作(比如删除、创建、写)而破坏我的restfulapi。

提前道歉,如果回复一个旧的帖子是不好的形式,所以。

@博宾塞

我不太在意将REST作为一个抽象的标准来遵守,但是如果不正确的、可泄漏的、可缓存的GET请求可能会意外地产生副作用,这确实是一个令人担忧的问题。

您可以使用一些策略来降低此类问题的可能性,例如要求每个API用户使用一个提交键和/或一次性使用submit键作为参数以允许操作继续进行。如果您允许通过JSONP对API进行写访问,那么无论如何都需要考虑这类问题,以防止XSRF攻击。

因此,由于缺少PUT、DELETE和POST动词,用JSONP实现真正的RESTful是不可能的。然而,许多jsonpapi仍然允许写操作。我隐约记得在Facebook的oauthjsonpapi中这是可能的。

不管怎样,如果URL中同时存在“callback=”和“method=”,并且method是GET、POST、DELETE或PUT中的一个,那么它将被视为一个真正的REST请求,那么似乎可以通过假设服务器端来实现一个假restfuljsonpapi。

这打破了REST的单一资源范例的单一URL,因为回调几乎每次都会改变,即使它保持不变,也会有4个URL表示,每个方法一个。所以我的问题是,这种打破RESTful范式的做法有什么后果,特别是关于你所担心的“散乱的、可泄漏的、可缓存的GET请求”以及潜在的“意外的”副作用?

处理cor(跨源资源共享)的一种新兴技术是使用HTTP访问控制。关于它的信息性文章可以在 Mozilla Developer pages the Kendo Blog W3 Site

Access-Control 帮助控制访问的标头。对于简单的GET/POST请求,只需返回 Access-Control-Allow-Origin header,对于使用其他方法的更复杂的请求,您需要额外的header,可以在上面的参考资料中找到。