Differences

This shows you the differences between two versions of the page.

--- 4thefile_api [2010/10/31 15:36] – jay
+++ 4thefile_api [2010/11/08 21:53] (current) – jay
@@ Line 2: / Line 2: @@
 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
@@ Line 9: / Line 10: @@
   * choice of XML or JSON response objects. more representations (e.g. jsonp) may be supported in the future
-===== Example Usage =====
+The [[4thefile_api_reference]] includes documentation and examples of all API resources.
-The Problem:
+===== Synopsis =====
-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.
+  - A 4theFile Collection provides a custom email address for submitting emails to a functional area of your site. The Collection is owned and controlled by you, and there's no need for your users to become registered 4theFile users.
+  - The 4theFile API allows you to integrate the list of emails submitted to the Collection into your site's interface, while avoiding all the messy issues usually associated with email integration.
-The Solution:
+===== Example Use Case =====
+**The Problem:**
+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.
+**The Solution:**
   - Register on 4theFile.com and set up a collection called "XyzProjects" with custom email address //xyzprojects@4thefile.com//.
   - 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.
@@ Line 38: / Line 46: @@
 ===== Authentication =====
-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:
+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:
   - The HTTP headers are encrypted (this is always true when using SSL/TLS encryption as is the case for https URLs)
   - The user never needs to share account credentials with a 3rd party service
@@ Line 46: / Line 54: @@
 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.
+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!//
+===== Use with AJAX =====
-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.
+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:
+  - your browser probably won't allow it, because you're violating the "same origin" policy that helps prevent malicious cross-site scripting (XSS) attacks
+  - you would need to provide access to your API credentials in the client-side javascript, thereby exposing them in the client-side source code
-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!//
+So, you'll need to provide your own ajax callback that in turn calls the 4theFile API from the server, or else provide a web proxy in the same origin as your server as described here http://developer.yahoo.com/javascript/howto-proxy.html
+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, [[tech_support_contacts | let us know]].

4theFile Support Wiki

User Tools

Site Tools

Differences

Page Tools