I have a site which tracks time spent working on projects for clients. It was created in classic Asp. I want to bill the time to the clients using the PayPal API. I am having a hard time determining which version I should use. I have read much of documentation and I am not sure which API to use (Classic vs REST).
I still prefer the Classic API. The REST API is still new to PayPal and is well behind the Classic API in terms of overall features.
Related
I am novice in Web API. Apologize if any question is not making sense.
I have several Web APIs developed in .NET and hosted on the same sever. These APIs are consumed by different applications. Here I wanted to monitor APIs. Monitoring includes:
How many applications are consuming my API?
How many hit counts to the API by different applications?
Is there any why we can restrict an application to access the application(ex. An application is given only 5 hits to the api per day)?
And also it would be helpful, if there are any tools available to do the same.
Thanks in advance
You can check out Treblle .Net SDK.
Treblle lets you monitor and observe your API and all the features you listed are packed in Treblle.
https://github.com/treblle/treblle-net
I need to make my own application with 90% of uber features
Can I build my own backend service using uber api?
I mean create my own server side and use uber algorithms,
Drivers and customers register with me not uber
Uber's software (including their API) is proprietary. This means you can use the Uber API to build apps that either help riders book rides or help drivers perform their tasks more efficiently, but you are not allowed to charge a fee atop Uber's base fee. Furthermore, Uber's algorithms for ride pricing and pathfinding remain closed-source and unavailable to Uber API developers.
On the other hand, you may be interested in LibreTaxi. Since it is released under the MIT license, the entire codebase is available for you to read, extend, and use to run your own services. You can operate a business using the codebase and charge customers.
By contrast, Uber's API only exposes an interface for use by client programs and some example apps. (i.e. Uber's Github repos do not contain the source code for their entire infrastructure.)
We are re-developing our eCommerce application and goingto use PayPal as our main gateway.
I am trying to figure out whether to use REST API or SDK.
Is SDK easier to use than REST API?
Which is better to use?
A good way to look at this is that the PayPal SDKs are built on top of the APIs (the root endpoints) in order to abstract out a lot of the complexities and keep integrations as up-to-date as possible.
If you are leveraging off of the API with your own code (and no SDK), you'll have to build out pieces for the auth (OAuth 2), in order to capture your access token, then build out calls for each endpoint that you wish to build against. Most of the time you'll see integrations like this if people want to highly customize their build against the API, or want to build in a language / integration not available in the SDKs.
The SDK will abstract out those complexities for you, so it'll definitely be the easier integration. In addition, the SDKs will be continually updated as the APIs change, so you won't have to update the code yourself to maintain that, just fetch the newest SDK version and test the integration.
If you're looking for the easiest integration, use the SDK. For Java, that's at https://github.com/paypal/PayPal-Java-SDK. There's also a number of quickstart samples at https://developer.paypal.com/docs/api/quickstart/ using the SDKs.
We have evaluated a few API management tools like WSO2 and Apigee.
The hard fact is that the level of REST architecture maturity of your back-end services made available on API Mgmt tool would decide how well your API design turns out to be on the much hyped API Management tools.
Which means you might end up re-writing your back-end services in case you would want to achieve a higher level of Maturity and API Management tools would be of no help there.
So my inference is API Management tools might help you manage, publicize or monitor your already designed API. Though these tools claim protocol mediation and light weight ESB features but that would make you digress from the original goal. And the practical implementation is not as seamless as the proponents of these tools make it sound.
I would rather use some ESB to implement well designed REST APIs and then use some API management tool for the purpose of managing and monitoring APIs.
And the irony is if your backend services are not well designed you would not leverage the API features to the best.
Please share your thoughts on this?
Thanks,
Wajid
I'd agree with your approach. I was recently involved in such an evaluation and we chose to ignore the features in those products aimed at 'constructing' APIs. We were looking for a product to publicize, manage access and monitor APIs, relying on backend systems to run the actual APIs.
Effort on getting RESTful APIs is aimed at those backend teams..
DocuSign highly recommends using the REST API instead of SOAP, and they push heavily for that in your initial implementation. They even suggest that new features may one day only be implemented in REST, which is my main concern. I'm leaning toward using their SOAP API anyway for our integration, and my primary question is this:
Let's assume the future scenario I fear - I build my DocuSign integration layer on the SOAP API. Next year, DocuSign does in fact leave the SOAP model behind, releases new features on the REST API only, and I desperately need to use one of those features. Is there any reason that I can't simply leave all of my SOAP integration in place, and implement integration with the new feature using the REST API? I understand that referencing both APIs would bloat the size of my deployment a bit, but I can accept that risk. Other than that, is there any compelling reason that I can't use both side-by-side? Would it break something?
It's perfectly acceptable to use a mix of DocuSign SOAP API and REST API in your integration. In fact, that's a very common scenario for the exact reason you mention -- some features are implemented only in SOAP or only in REST, so it's often necessary to use a mixed approach in order to get the full functionality that you require.