PayPal 文档(REST、经典:SOAP 和 NVP)选择什么? [英] PayPal documentation ( REST, Classic : SOAP & NVP ) What to choose ?

问题描述

我需要使用 PayPal API 开发支付解决方案.实际上我开始了文档阶段(在 http://developers.paypal.com 上)

I need to develop a payment solution using PayPal APIs. Actually I started the documentation phase ( on http://developers.paypal.com )

我发现 REST API 可以理解，但我仍然不知道如何使用 SpringMVC 实现它们，所以我只是使用 cURL 来测试它们.(对此有帮助吗?)

I found the REST APIs understandable, I still don't have an idea how to implement them with SpringMVC so I'm just using cURL to test them. ( any help on this ? )

另一方面，经典 API 令人困惑.(例如，我们可以用自适应账户做什么以及快速结账和自适应支付之间有什么区别等.).

On the other hand, the Classic APIs are confusing. ( for example what can we do with the Adaptive Accounts and what's the difference between Express Checkout and Adaptive Payments, etc.. ).

另一件事是，我们需要在创建隐藏表单 (html) 或使用 API 之间做出选择.(我需要解释)

Another thing, is that we need to choose between creating a hidden form ( html ) or using APIs. ( I need explanation )

文档很长，我真的很困惑，我不知道该选择什么(显然 REST API 更适合简单的支付，但我真的很想了解更多关于SOAP & NVP .. )

The documentation is very long and I'm really confused, I don't know what to choose ( obviously the REST APIs are better for simple payments, but I really want to know more about the SOAP & NVP .. )

我是新手，有人可以成为志愿者并帮助我吗?

I'm novice, s can someone be a volunteer and help me on this ?

谢谢！

推荐答案

已经完成了几次 PayPal 集成舞蹈(尽管是几年前)让我总结一下我的想法(并记住，事情可能会略有变化)

Having done the PayPal-integration-dance a couple of times (albeit a few years ago now) let me summarize my thoughts (and bear in mind, things may have changed slightly)

PayPal 拥有大量 API/集成方法的原因是因为他们希望能够刺痛您支持付款的众多地方:

The reason for PayPal's profusion of APIs/integration methods is due to the vast array of places they want to be able to sting you for support payment from:

• 如果您只有博客、静态 HTML 托管、现成的电子商务网站或其他一些原始"网络技术，提交隐藏的 HTML 表单 几乎是您唯一的选择.我怀疑这是 PayPal 使用的原始机制，虽然他们必须永远继续支持它，但您今天不想从现代网络框架中使用这种方法，例如SpringMVC.

• If all you have is a blog, static-HTML-hosting, off-the-shelf eCommerce site or some other "primitive" web technology, submitting hidden HTML forms is pretty-much your only option. I suspect this is the original mechanism PayPal used, and while they have to keep supporting it forever, you wouldn't want to use this approach today from a modern web framework like SpringMVC.

NVP API是另一种长期存在的集成方案，它适用于将参数有效地拼接到 URL 中是您的客户所能做的所有事情.现在 REST JSON API 可用时，没有充分理由使用此 API - 大多数人发现 JSON 比 URL 编码的参数更容易阅读.

The NVP API is another longstanding integration scheme which was appropriate at a time when effectively stitching together parameters into a URL was all your clients could do. There's no great reason to use this API these days when the REST JSON API is available - most people find JSON much easier to read than URL-encoded parameters.

我怀疑接下来按时间顺序介绍，SOAP API 反映了 XML 将统治世界的时代.在某些(非常严格和/或传统)的地方，它仍然如此.同样，如今，如果您有选择，您可能不会走这条路 - Java 的使用通常涉及与 SOAP 框架的紧密集成，例如 Apache CXF 和大量机器生成的 .java 文件.

Chronologically introduced next I suspect, the SOAP API reflects a time when XML was going to rule the world. In some (very strict and/or traditional) places, it still does. Again, these days, you probably wouldn't go down this path if you have a choice - usage with Java generally involves tight integration with a SOAP Framework like Apache CXF and mountains of machine-generated .java files.

REST API 是最现代的和(恕我直言)最好从 Java-land 使用，这是我推荐的选项.看起来 PayPal 也希望您使用它，所以这就是我将在本答案的其余部分讨论的内容.

The REST API is the most modern and (IMHO) nicest to use from Java-land, and is the option I recommend. It's looks like it's what PayPal would prefer you to use too, so it's what I will spend the rest of this answer talking about.

作为 Java 开发人员，当您选择 REST API 时，您可以进一步选择使用 PayPal 的 SDK 或滚动您自己的集成方案.在以下情况下考虑使用 SDK:

As a Java developer, when you select the REST API you get a further choice of either using PayPal's SDK or rolling your own integration scheme. Consider using the SDK if:

• 您可以预见您的 PayPal 集成将变得非常庞大和/或使用高级 API 功能

• You can foresee your PayPal integration becoming very large and/or using advanced API features

您没有任何其他 HTTP 集成点，因此还没有用于从您的代码调用 HTTP 方法的基础结构(例如 Apache HttpClient 或 RestTemplate 功能内置于 Spring 3 )

You don't have any other HTTP integration points and so don't already have infrastructure for calling HTTP methods from your code (e.g. Apache HttpClient or the RestTemplate functionality built into Spring 3 )

您没有(或不想拥有)可用的 JSON 解析器

You don't have (or don't want to have) a JSON parser available

由于您已经通过 cURL 使用过 API，并且您了解调用及其顺序，因此您可能对此尚未决定.如果您没有太多时间压力，我建议您使用(并学习)Apache HttpClient 以及像 Jackson - 它们是您的武器库中的宝贵工具，您几乎肯定会在未来的集成中再次使用它们.

As you've already been using the API via cURL and you understand the calls and their sequencing, you're probably undecided about this. If you're not under too much time pressure, I'd recommend going down the roll-your-own path using (and learning) Apache HttpClient together with a JSON library like Jackson - they are valuable tools in your arsenal and you'll almost certainly use them again in future integrations.

另一个开发技巧，适用于任一 REST API 选项 - 如果您使用存根服务器"，例如 这个 模拟 PayPal 的连接结束，它会记录它收到的每个请求的详细信息并做出适当的响应.这对于准确调试通过网络"输出的内容和/或重复测试内容来说是天赐之物.

One other development tip, which applies to either REST API option - if you use a "stub server" such as this one to simulate PayPal's end of the connection, it'll log the details of every request it receives and respond appropriately. This can be a godsend for debugging exactly what is going out "over the wire" and/or testing things repeatedly.

这篇关于PayPal 文档(REST、经典:SOAP 和 NVP)选择什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！