据我了解，JSONP 只能使用 GET 动词来实现。假设我认为这是真的，那么这就排除了与真正 REST 的核心合规性，在这种情况下，您应该使用不同的动词，即 GET、PUT、POST、DELETE 等......用于不同和特定的目的。
我的问题是，如果我说允许使用 JSONP 服务使用 get 请求更新和删除资源，我可能会遇到什么类型的障碍。
提供 JSON 服务并声明用户需要服务器端代理才能使用 JavaScript XDomain 消费是更好的做法吗？
干杯，
安德鲁
【问题讨论】：
处理 CORS（跨源资源共享）的新兴技术是使用 HTTP 访问控制。可以在Mozilla Developer pages、the Kendo Blog 上的文章和W3 Site 上找到有关它的信息性文章
总之，在服务器端，您需要返回几个Access-Control 标头来帮助控制访问。对于简单的 GET/POST 请求，您可以简单地返回一个 Access-Control-Allow-Origin 标头，对于使用其他方法的更复杂的请求，您需要额外的标头，可以在上述资源中找到。
【讨论】：
如果在 SO 上回复旧帖子是不好的形式，请提前道歉。
@bobince
我不太担心“遵守”作为抽象标准的 REST，但如果杂散、可泄漏、可缓存的 GET 请求意外产生副作用，这是一个真正的问题。
您可以使用一些策略来降低发生此类问题的可能性，例如要求每个 API 用户和/或一次性使用的提交密钥作为参数以允许操作继续进行。如果您允许通过 JSONP 对 API 进行写访问，那么无论如何您都需要考虑这种事情，以防止 XSRF 攻击。
由于缺少 PUT、DELETE 和 POST 动词，因此 JSONP 无法实现真正的 RESTful。但是，许多 JSONP API 仍然允许写入。我隐约记得这在 Facebook 的 OAuth JSONP API 中是可能的。
无论如何，如果 URL 中同时存在“callback=”和“method=”且方法是 GET、POST、DELETE 或 PUT 之一，则似乎可以通过假设服务器端来实现虚假的 RESTful JSONP API那么它将被视为真正的 REST 请求。
这打破了 REST 单一资源范例的单一 URL，因为回调几乎每次都会改变，即使它保持不变，也会有 4 个 URL 表示，每个方法一个。所以我的问题是，这种打破 RESTful 范式的后果是什么，特别是关于您对“杂散、可泄漏、可缓存的 GET 请求”以及潜在的“[意外] 副作用”的担忧？
【讨论】：
JSONP 是一种安全边界解决方法（仅允许在同一域上调用 ajax）。如前所述，它非常有限，只能用于只读（通过 html 脚本/src 包括 HTTP GET）。为此，它简化了集成和混搭，无需服务器端代理发出真正的 api HTTP 请求。
但我绝不会为了让 jsonp 执行任何写入操作（如删除、创建、写入）而破坏我的 Restful api。
另一个大缺点是安全性：JSONP 调用由浏览器触发，用户名/密码传输无法正常工作（它在请求中清晰可见）。对于许多 api 禁用写操作的身份验证是不行的。即使您使用服务器生成的一次性令牌，这也是危险的，因为您可以通过使用“curl”之类的工具恶意滥用它。
【讨论】：
据我了解，JSONP 只能使用 GET 动词来实现。
是的。
幸运的是，简单的幂等信息 GET 请求是跨域 JSON 的最常见用例。
这排除了与真正 REST 的核心合规性，您应该在其中使用不同的动词，即 GET、PUT、POST、DELETE 等
是的。
我不太担心“遵守”作为抽象标准的 REST，但如果杂散、可泄漏、可缓存的 GET 请求意外产生副作用，这是一个真正的问题。
您可以使用一些策略来降低发生此类问题的可能性，例如要求每个 API 用户和/或一次性使用的提交密钥作为参数以允许操作继续进行。如果您允许通过 JSONP 对 API 进行写访问，那么无论如何您都需要考虑这种事情，以防止 XSRF 攻击。
【讨论】：
JSONP 非常有限，因为它包含使用<script> 标签的脚本，然后对某个处理的函数进行回调。
就我个人而言，我更喜欢真正的服务。编写服务器端代理并不难，并且可以让您更好地控制它（如超时、错误处理、其他类型的请求等）
【讨论】：