JSONP对真正REST的影响

Question

根据我的理解，JSONP只能使用GET动词来实现。假设我认为这是真的，那么这就排除了对真正REST的核心遵从性，你应该在其中使用不同的动词，即GET，PUT，POST，DELETE等......用于不同的和特定的目的。

我的问题是，如果我说允许使用get请求使用JSONP服务更新和删除资源，我可能遇到什么样的障碍。

提供JSON服务并说明用户需要使用JavaScript XDomain来使用服务器端代理是更好的做法吗？

干杯，

安德鲁

Answer 1

  

根据我的理解，JSONP只能使用GET动词来实现。

是

幸运的是，简单的幂等信息GET请求是跨域JSON的最常见用例。

  

这排除了核心对真正REST的遵从性，你应该使用不同的动词，即GET，PUT，POST，DELETE等

是

我并不太担心“遵守”REST作为抽象标准，但如果流浪，漏洞，可缓存的GET请求可能会偶然产生副作用，那么这是一个真正的问题。

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

Answer 2

JSONP非常有限，因为它包含使用<script>标记的脚本，然后对某些处理函数进行回调。

就个人而言，我更喜欢真正的服务。编写服务器端代理并不困难，并使您能够对其进行更多控制（如超时，错误处理，其他类型的请求等）。

Answer 3

JSONP是一种安全边界解决方法（仅在同一域上允许ajax调用）。如上所述，它非常有限，只能用于只读（HTTP GET到html脚本/ src包括）。为此，它简化了集成和mashup，而无需让服务器端代理发出真正的api HTTP请求。

但是我永远不会破坏我的Restful api只是为了让jsonp做任何写操作（比如删除，创建，写）。

另一个重大缺点是安全性：JSONP调用由浏览器触发，用户名/密码传输无法工作（在请求中明显可见）。对于许多apis禁用的写操作认证是不行的。即使您使用服务器生成的一次性令牌，这也很危险，因为您可以通过使用“curl”等工具来恶意滥用它。

Answer 4

如果在SO上回复旧帖子的形式不好，请提前道歉。

@bobince

  

我并不太担心“遵守”REST作为抽象标准，但如果流浪，漏洞，可缓存的GET请求可能会偶然产生副作用，那么这是一个真正的问题。

     

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

由于缺少PUT，DELETE和POST动词，JSONP无法实现真正​​的RESTful。但是，许多JSONP API仍然允许写入。我模糊地回忆起它可以在Facebook的OAuth JSONP API中使用。

无论如何，如果URL中存在“callback =”AND“method =”并且方法是GET，POST，DELETE或PUT之一，那么假设服务器端似乎可以实现一个虚假的RESTful JSONP API。那么它将被视为真正的REST请求。

这打破了REST的单一资源范例的单个URL，因为回调几乎每次都会改变，即使它保持不变，也会有4个URL表示，每个方法一个。所以我的问题是，这种从RESTful范式中突破的后果是什么，特别是关于你对“流浪，漏洞，可缓存的GET请求”的担忧以及潜在的“[意外]副作用”？

Answer 5

处理CORS（跨源资源共享）的新兴技术正在使用HTTP访问控制。有关它的文章可以在Mozilla Developer pages，the Kendo Blog上的文章和W3 Site

上找到。

总之，在服务器端，您需要返回一些有助于控制访问的Access-Control标头。对于简单的GET / POST请求，您只需返回Access-Control-Allow-Origin标头，对于使用其他方法的更复杂请求，您需要额外的标头，可以在上述资源中找到。