The 4theFile API provides RESTful web services for use in integrating 4theFile with other web-based applications. The API has the following features:

• all communication via HTTP or HTTPS
• authentication via HTTP Basic auth
• easy to understand and learn
• easy to call from any modern programming language
  • fully working sample implementation of a perl client library available, with source code and tests
• choice of XML or JSON response objects. more representations (e.g. jsonp) may be supported in the future

The Problem:

You've developed a project management database. 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 satisfying. So you'd like a better way to associate these emails with a the right project records.

The Solution:

1. Register on 4theFile.com and set up a collection called “XyzProjects” with custom email address xyzprojects@4thefile.com.
2. On the detail page for project #235 in your application, provide a mailto: link and instruct users to forward relevant emails to xyzprojects+235@4thefile.com. The ”+235” part of the email address is called a “tag” in 4theFile.
3. In the application code that generates the detail page,
   1. use the 4theFile API to retrieve the list of 4theFile resources for collection XyzProjects that have tag 235. The response will be a chunk of XML or JSON that describes the list of 4theFile resources that match. The response will NOT include the content of the emails in the collection, but rather the “meta data” such as the subject, the From address, etc., as well as an http or https link to the full resource content on 4theFile.
   2. Parse the response and use the contents to present the user with a clickable list of the resource descriptions for emails relevant to your project.

This simple example required one (count 'em, one!) API call, a simple HTTP GET to a url that looks something like this:

https://4thefile.com/api_v1/collections/XyzProjects/resources?tag=235

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.

1. register on 4theFile
2. request an API key from 4theFile support
3. set up a collection in your 4theFile account, and get the email address and collectionkey for your collection
4. get an HTTP client library for your language of choice. It needs to support Basic auth (required) and SSL (recommended). Most do. You could even start with a command-line client like Curl (available on all platforms) or lwp-request (linux)
5. Make a test GET to

   https://4theFile.com/api_v1/collections/<collectionkey>/resources.xml

   • use your 4theFile account username for the Basic auth username, and your 4theFile apiKey (NOT your 4theFile login password) for the Basic auth password. You should get back a status code of 200 and a chunk of XML content (if everything is good), or a non-200 status code and an explanation in the content if there's a problem.
6. go read the 4theFile API Reference to learn what else you can do with the API

Authentication is performed via Basic authentication, an HTTP standard that's been around for a long time. Basic auth is not very secure when performed over an unencrytped connection, since anyone snooping on the wire can read the username and passord (“credentials”) in the HTTP headers. However, Basic auth is quite secure under 3 conditions:

1. The HTTP headers are encrypted (this is always true when using SSL/TLS encryption as is the case for https URLs)
2. The user never needs to share account credentials with a 3rd party service
3. There is no need for “session management” functions such as inactivity logout.

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.

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.

Undoubtedly there are uses of the 4theFile API we haven't thought of. If there's a need, 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 accounts, please let us know. Please do NOT ask your users to give you their 4theFile passwords or apiKeys!