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.
Related
We are in the process of designing a front-end application with Angular which will call a jBASE server through RESTful APIs. APIs are created from jBASE component called jAgent.
Does jAgent support creating and verifying JWTs?
If not, what is the best way to handle authentication/authorization for the Angular application?
If we need to use JWTs, do we have to use a authentication middleware application (.NET Core or node.js) for that?
Great question! At the moment there is no handler within jAgent and our recommendation is to implement this, and advanced web server/API gateway technology by way of other applications like HAproxy or Kong.
An expansion of jAgent functionality to include things like this is something we're still considering but keep in mind, the power of jBASE lies in its native interactions with the host OS. Since there is no virtual OS layer it can be easier to plug and play off the shelf things to fill in for additional functionality, which gives you the flexibility to bring your own tooling.
In summary:
Not at the moment
Using an off the shelf package to act as your API gateway
Subject to the package you choose
That relegates jAgent to management of the API layer as it exists on the PICK/jBASE side while the off the shelf package manages your API security layer.
One other note for you--I noticed that you included a link to the old jBASE docs hosted on HelpJuice. It's worth mentioning that we've migrated those docs to docs.zumasys.com. You'll find the docs there to be more up to date, and also completely open sourced--part of the migration included their move to a GitHub repo, where we're happy to take community contributions.
For reference, the article you mentioned is available at https://docs.zumasys.com/jbase/connectivity/jagent/introduction-to-jagent-rest-services/.
Update:
One of our engineers has a program that will use openssl to generate the tokens for you, which you can find at https://github.com/patrickp/wjwt.
You will need openssl installed on the machine and in the path.
The WJWT.TEST program shows the usage. The important piece is the SECRET.KEY which is your internal KEY you use to sign the payloads.
When a user first authenticates you create the token with SIGN. Claims are any items/fields you wish to save/store. Do NOT put sensitive data in here as it is viewable by anybody. The concept is we sign this with our key, give it back to the client. On future calls the client sends the token and we pull it and call the VERIFY function which basically re-signs the payload and validates the signatures match. This validates the payload was not manipulated.
Activities such as expiration you would build into your code.
Long term we plan to take this library and refactor the code into our MVDB Toolkit library with more functionality. That library is something we provide to jBASE customers at no additional charge.
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.)
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.
I was surfing the Internet where I found an article saying that Alfresco is a Content Management Framework as well as App Development Framework. While I understood it as Content Management Framework, I am not able to know about it as an App Development Framework.I tried researching over it, but could not find anything viable.
I want to know that how Alfresco can be used as an App Development Framework ?
Hi Alfresco has an application development framework, more info here:
Guides: https://community.alfresco.com/community/application-development-framework/pages/get-started
Angular 2 components repository: https://github.com/Alfresco/alfresco-ng2-components
Alfresco App Yeoman generator: https://github.com/Alfresco/generator-ng2-alfresco-app
JavaScript API repository: https://github.com/Alfresco/alfresco-js-api
Some videos:
https://www.youtube.com/watch?v=-OFI3izSDdk
https://www.youtube.com/watch?v=kjOgVbINAyU
In case you want a live support you can use the Gitter channel: https://gitter.im/Alfresco/alfresco-ng2-components
Well, if for App is meant mobile application, Alfresco has a Mobile SDK available for both iOS and Android which can help you create your own application to work against the Alfresco Platform.
Moreover there is another framework called Aikau which has one main goal
The main purpose of Aikau is to provide a library of widgets that can be easily assembled into a web application for accessing an Alfresco repository. The aim is not to replace Share but it was necessary to migrate away from its original implementation, which was based around the Surf paradigms of pages, templates, components and web scripts, towards a solution that provided for rapid development and customization.
This feature was first introduiced in Alfresco 4.2 and then extended in Alfresco 5.0
If you want to build applications for Alfresco you have a number of options available to you - as mentioned you can build mobile applications (and there are SDKs available to do this).
If you want to build web applications then you have the option of either customizing the default Alfresco Share client (which is built on top of the Alfresco Surf framework using a combination of YUI 2 and Aikau). Alternatively you can built your own web client by building a new client with the Maven Aikau Archetype.
The advantage of the Surf framework is that it takes care of Alfresco authentication across all the various APIs (WebScript, CMIS, Public API, etc) as well as providing lots of security benefits (CSRF, XSS white-lists, etc).
The advantage of using Aikau is that it provides a large number of out-of-the-box widgets that are specifically designed to work with Alfresco data and address Alfresco (ECM) specific use cases.
You are of course not limited to these options - you can build an application on top of any stack you wish, but ultimately you will want to be making use of the REST APIs that the Alfresco Repository provides.
Depending upon the application you are building you may also want to build custom data models and build in workflow via Activiti BPM as well.
I have found some strategies for versioning REST APIs via SO and Google etc., but I have not found any strategies for versioning internal REST apis (and I mean by this, that I intend making a web app, an Android app etc that share a common REST api, but the general public will not get access to the API).
Seeing as the API is for internal use only, it would need less backwards compatibility, and basically a way of being 'current' and 'edge' or something similar. Any tips on a nice and simple strategy to version an internal REST api for minimal hassle would be great.
current is a very bad way to differentiate. If you have an application which carries out a call to /current/users, and then you upgrade your API so that /current/users returns different information, your application will break.
Stick with versioning. A simple /v1/users is clear and concise, and when you add /v2/users then the applications using the old API endpoint will continue to work and you can update them as and if you require.