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令人困惑. (例如，我们可以使用Adaptive Accounts做什么，以及Express Checkout和Adaptive Payments之间的区别是什么.).
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-integration-dance(尽管几年前)，让我总结了自己的想法(请记住，事情可能会发生有所改变)
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:
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 strong> 反映了XML统治世界的时代.在某些(非常严格和/或传统)的地方，它仍然会这样做.再有，如今，如果您有选择的话，您可能不会走这条路-Java的使用通常涉及与SOAP Framework的紧密集成，例如 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 是最现代的和(IMHO)在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方法的基础架构(例如
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 和JSON库(如
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选项-如果您使用的是存根服务器"，例如
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屋！
