The 4theFile API
- Perl Client Library reference implementation
The 4theFile API provides RESTful web services for use in integrating 4theFile with other web-based applications. The API has the following features:
The 4thefile_api_reference includes documentation and examples of all API resources.
You've developed a project management system called XyzProjects.com. It includes an interface for adding notes or uploading attachments for each project. But you've realized that often the content for these notes come in the form of email, and cutting and pasting those emails into your “notes” text area isn't very effective or convenient. So you'd like a better way to associate these emails with a the right project records.
This simple example required one (count 'em, one!) API call, a simple HTTP GET to a url that looks something like this:
and a few more lines of code to parse out the relevant fields from the 4theFile resource objects in the response and display them with clickable links in your application.
Authentication is performed via “Basic” authentication, an HTTP standard that's been around for a long time and is well supported in HTTP client sofware. Basic is an effective and secure authentication mechanism under 3 conditions:
These conditions are met when using the 4theFile API over the https endpoint, so Basic is an appropriate and secure authentication method.
Q: Why did Twitter decide Basic auth wasn't secure enough?
A: The Twitter API was designed to solve a different type of problem than the 4theFile API. Third-party sites that use the Twitter API (such as TwitPic.com, for example) usually need access to an individual end user's Twitter data. When you used the original version of TwitPic, they'd ask you for your Twitter password and then they would use that password to post your pictures to your Twitter account via the API. Not to pick on TwitPic, but the risk here is that now you need to trust both Twitter AND TwitPic to protect your Twitter credentials. As the number of 3rd party sites that use the Twitter API grew, this situation got out of control, and a new solution was needed. The delegated API authorization approach called OAuth was designed for this precise scenario, and OAuth is now the only auth scheme supported by the Twitter API. In a nutshell, OAuth requires the end users to log in to their Twitter account and approve a request for access to their data by the 3rd party API. OAuth includes a clever mechanism for making this transaction fairly transparent to the end user.
The 4theFile API, in contrast, is designed to access data that belongs to the 3rd party site (the “API client”), not data that belongs to that site's users. The API client site has its own 4theFile account and its own credentials, and doesn't need to access any other 4theFile users' data. In fact there is no need for the API client site's users to register on 4theFile at all. Since only the API client must be authenticated by 4theFile, Basic auth is suitable authentication solution, and in fact OAuth would not be a good fit.
Undoubtedly there are uses of the 4theFile API we haven't thought of. If there's a need for delegated authorization for access to data not owned by the API client account, we'll support OAuth in the future. If you are an application developer or maintainer and have an idea for using the API to access 4theFile end-user data, please let us know. Please do NOT ask your users to give you their 4theFile passwords or apiKeys!
If your web application's interface uses AJAX, you might be thinking that you can call the 4theFile API to get a 4theFile resource list in json format directly from inside the browser via XMLHttpRequest. There are 2 reasons why this isn't a good idea:
Note: If you've read this far, you may be familiar with JSONP (an alternate solution to cross-domain ajax problems). We'd probably be willing to support JSONP as an alternative response format in the future if there's any demand for it. So if you'd like JSONP, let us know.