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.)
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 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
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.
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.
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..