I'm working on an app and websites. They have related information such as users, contracts, etc. What is the reason for designing an API and not connecting directly to the database?
Edit:
I'm just starting development and have no experience with web services. Please be as thorough as possible.
Sites such as Facebook, Google, and Twitter could never let third party apps connect directly to their database: it's an enormous security risk. (Would you be comfortable if Facebook allowed anyone to access their database, including private user information and messages?)
APIs serve as a gate through which third party apps can get the kinds of information they are permitted to access.
There are several reasons why you would use an API instead of using direct access.
The first 2 that come to mind:
Using an API allows you to write the client code without knowing any details of the specific implementation, so if you change your database structure or location for instance, you need only rewrite the API wrapper code, not everywhere its referenced.
It allows you to have different levels of authentication. As mentioned in another answer, it is not ideal for all users of an application to have access to every other users data.
Related
I am working on a cross platform app that will be created using C++-> mobile devices, and using Perl-> Desktop PCs (like Windows /Linux/Mac OS).
Now, since the app will be downloadable, I have concerns regarding the ability of hackers to obtain the source code of my app.
Specifically, the app will connect to my central database-- at the minimum, I want that hackers are not able to obtain my database connection details. Ideally, I would want no part of the code to be hacked.
Basically, the user can update some of his information using this app-- if hackers get hold of this data they can easily change any unfortunate user's data. One thing that I have thought of is that the user will have to initially authenticate with OAuth/OAuth2 ( using his email ID #yahoo/#hotmail/#gmail)-- and only after that the app will actually show the admin interface. But at any rate, at some point the app will connect to the central database-- which is why I dont want the database's access details to be compromised.
Many organisations make such apps, so they must be facing this type of problem themself? I would like to know how I can protect my app (ideally entire code), and atleast the db credentials.
The simple answer is you do not expose your database. Ever.
Add a service layer (could be HTTP-based but doesn't have to be) on top that will deal with authentication and authorisation. Your app then logs in using the user's credentials and acts on their behalf. Your service layer exposes an API which your application talks to, but your service makes and controls all calls to the DB.
You already mention OAuth - that's a perfectly acceptable way of adding authentication to such an API.
You cannot.
On the bright side you can put security on your server. The connecting client provides credentials that they are a given user. The server generates the SQL command after proving the request is allowed. Backers can do anything your app can do, but your app becomes incapable of behaving badly to your database.
The previous answers are absolutely correct. You want a server based service layer that provides the authentication/authorization code and interacts with the database. However, it isn't always a perfect world and if you are stuck with the requirement that these applications must act as a database client you want to limit the exposure as much as possible. Typically this is done by having the client use a specific account which has not been granted any access to the general database. You then create specific stored procedures that can only do the operations and queries that are required of the application. This prevents anyone finding the credentials in the code from doing anything in the database that isn't intended, but you still have the problem that anyone can impersonate someone else by reviewing the code. There isn't a way to prevent that without a server side component. This might be okay for a closed/trusted group of users, but I wouldn't release anything to the general public with this method.
If you can do it, use OAuth2 and allow a trusted third party handle authentication. Twitter, Facebook and GitHub are all relatively paranoid about security; and the other poster is correct: never expose direct db access as part of the app the user has access to; put it behind a service of its own.
Good luck! :)
I am newbie here and confused by few things
Some websites (twitter, foursquare, etc) provide API to third-party developer to call. are those APIs the web services that the sites provide?
Are those web sites themselves built on top of those public APIs/web services? theoretically is it possible?
Comparing the traditionally built website and the websites build on top of web service, pros and cons? are there any performance, scalability, etc differences?
Thanks in advance!
I'm sure somebody can give you a more exact answer but reading your question and applying my self-taught knowledge:
The simple technical definition of Web Services according to W3C:
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network.
http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/
I like to think of web services as the interactive elements of a site that its customer base utilizes. For example, Twitter's web services include: tweeting, messages, hashtags, etc. Web services are what users get to DO or DATA passed back and forth.
A public web API provides means for developers to utilize the web services on their own site. For example, Twitter's API allows example.com site to utilize tweeting, messaging, hashtags, etc from within their own domain. An API is how developers get external access to web services to make apps using those services.
I have no idea about this question. I wouldn't do that. I would use the methods the public API exposes access to. But, I've never written my own API, let alone on the scale of Twitter or foursquare.
I hope this helps.
First of all, maybe you need some more info about what an API is: please take a look at the Wikipedia api page.
To answer to you questions (these are only general thoughts and not best practices):
An API, in this case, is a way that a developer uses to access a webservice, and it's not the service itself.
The websites you mention are not using their own APIs, as these APIs are meant for remote users (clients), and offer limited data sets, while the websites need maximum performance, access to the full database, and (almost) always use server-side code. The websites you mentioned, probably use other, server-side, high-performance APIs.
See the previous point: although it depends highly on which APIs you use, what you call "traditionally built websites" (that is, web applications using server-side APIs) can afford higher performance than websites totally built on top of remote APIs, because they do not depend on the bottleneck of the network connection (because, again usually, the web server and the database server either run on the same machine, or communicate faster than the client's browser and the server).
The reason that would make most people choose to develop a webapp the traditional way is that free APIs provide limited functionality (e.g. Google custom Search, limited to 100 reults).
I am trying to build an application that will use data from multiple social services. The user will need to authorize their accounts to be accessed across these multiple services (e.g. facebook, twitter, foursquare) using oauth.
I don't really need the users to login with these accounts, really it is just allowing their data from the api to be pulled.
I know I need to use oauth, but I am having trouble finding a basic example of how to do this type of thing (a lot of examples exist for logging in with oauth).
I have been trying the python-oath2 library.
Does anyone have any recommendation for a good tutorial or example of doing this type of thing in python, and if possible django.
Thanks.
Why reinvent the wheel? There is a plethora of reusable applications that have this implemented. You can find a comparison here: http://djangopackages.com/grids/g/authentication/
Why not give rauth a try? We use this in production for this exact purpose. Although you don't need to require the user to login with your app via the provider, you're going to redirect to the provider, where they'll be asked to authenticate your application. Assuming they accept (or even if they don't), they'll be redirected back to your application, i.e. via the redirect_uri or oauth_callback, there you'll ensure they authorized your app and then proceed with whatever housekeeping you need to do, e.g. saving some info about the user in your database. Try the examples and also pay particular attention to the Facebook example. Now the Facebook example is intended for authorization with the example web app, but the same pattern can be used for what you're trying to do. (You just won't be having them login in via Facebook, for instance. However, the flow can be and probably should be identical, sans database operations and template login lingo.)
We're setting up a website that schedules video-conferencing sessions for end-users (using our own technology). We're interested in providing access to this functionality to "corporate clients" to use through their own site.
Initially, we were thinking of having an API key given to each corporate client, and modules could be built in any language to fetch the data from our site. However, our requirements are changing and we're exploring how the data should still be visible to the user of the 'corporate client' even if a network disconnection takes place between their server and ours.
What are the mechanisms by which a website can provide access to its data / functions to other websites?
I would suggest, REST. REST is a lightweight software architecture designed to facilitate access to resources over HTTP/HTTPS.
REST constraints state that there is a separation of components and language agnostic interfaces among others, so your clients won't have to worry about using Java because you're using Java, for example. Aditionally, REST web services are supposed to be cacheable, which may help fit your desire to avoid network issues.
You can learn more about REST here:
http://en.wikipedia.org/wiki/Representational_State_Transfer
Several web service APIs have you sign up for an API key. For example, UPS Web services requires a key, which is included in calls to their service -- In addition to the username and password.
What is this key used for by the provider? Perhaps UPS is the only one to require both API key and username/password?
One idea is that they use it to limit or measure API usage, but it seems to me that a setting in the users profile could easily do the same thing -- especially since you generally have to get an account w/ username and password to get the API in the first place.
There are two predominant use cases. The first is to measure, track and restrict API usage. If someone is building a service that allows third parties to access it, the service provider may want to control (or at least know) who has access so that they can try and prevent things like denial of service attacks. On the measure and track side, interesting information can be obtained such as knowing which applications are popular for accessing the service or which features people use the most.
The other use case is related to security and authentication. It is unwise for a service provider to have third party applications and services require users to give up their username and password for the primary service. This is a huge exposure. That is why many services are standardizing on protocols such as OAuth, which provides delegated access via authorization to a user's data. While not foolproof, it is definitely preferable to distributing user credentials to unknown, and untrusted, parties.
Most of the time it is to monitor how developers are using the web-api. If they somehow disagree with your usage of the api it provides a means for them to shut it/you down without hurting the other users. And the statistics per user/app are always valuable.
I've used the flickr api - in that situation the key is yours, but the login data might be those of people using your app, so the api key is the only way to differentiate between the apps.
Usually it used to get stats on how much application performing queries to API.
I think asking username/password with API key is ambigious in some cases, but it is a way how it is implemented - so we can't do something with it.
They ask for API key because you could have more than one API under same account - in case you have more than one site which are use same API.
They could use it to signify which version of the API you are trying to use. Perhaps in Version 1.0, there is a method that takes a POST on www.UPS.com/search and there is another one in version 2.0 at the same address, but takes a different parameter set, or even returns data in a different format/style. Your program was built on V1.0 and expects a certain API contract. They want to be able to create V2.0 without interfering with their customer's products.
That's just a guess, but it sounds good to me.
I think Gracenote does a similar thing for cddb. I forget the details, but I remember something about some token.
(They have/had really draconian rules about using their service too.)
Simon reminded me what the gracenote thing was. Gracenote and Fedex and other webservices have lots of developers writing apps for the software. So the developers get a token to put into their apps, but the end users have their own user name and password. It lets the services keep an eye on abusing programs, etc. That is probably te primary reason. (like a browser or a webbot informing the webserver who/what it is)
Originally, Blogger required you to apply for an API key (a la Google Maps) and used it to restrict access to the API. As Blogger evolved into Metaweblog, the requirement for the API became less important, and Blogger no longer requires you to apply for a key. As noted by others, it can still be used for tracking purposes.
In our situation, our clients want it for:
Tracking/analytics - figuring out who's doing what and building what products. Because a number of users are desktop apps, just looking at referrers isn't always enough.
Permissions - which resources should a user have access to? How can a user build apps that have access to specified resources?
Licensing/legal - enforcing that users have read and accepted ToU/licensing information.
Security - passing around usernames/passwords is a really bad idea.