Intelligent Design : RESTful API

The Fellowship One REST API is alive!

FTProductDev — Mon, 08 Jun 2009 21:50:00 GMT

A year has passed since we announced the thoughts behind having a new API for the community. We spent a lot of time engaging you, crafting code, building applications, and working on solidifying what turned out to be a retro-revolution... read more at our our new developer community site.

DC09 - DevCon Code, Slides, Videos

FTProductDev — Tue, 26 May 2009 04:50:00 GMT

We have wrangled all of the devs and gathered all of the content that you saw at the DC09 DevCon. Since we are community focused, we wanted you to have as much code and information that you'd need to get jump started for the RESTful API BETA so that you'll be able to discuss / communicate your ideas on consuming the REST API throughout the Social-Sphere. We've got much more to come with the upcoming launch of our developer community site and the general release of the REST API. Please take a moment to check out the goodies below - the whole dev team really "kicked out the ladder" so that we could give you real world, ministry focused code.

Application #1: F1Touch (Team Fire - iPhone) – 1st Party
Developers: Matt Vasquez, Chad Meyer
Description:
Our app is an iPhone application as a first party vendor open to all churches that opt in. Our application will provide the ability for church portal users to quickly look up congregants and contact them via phone or email as well as pull up Google maps to assist in directions to their house.

Content
Chad Meyer's blog post | Slide Deck | OAuth Lib

Application #2: Outreach (Team Air - Facebook) – 3rd Party
Developers: Ryan Champ, Jas Singh, Kelly Klein
Description:
Facebook is a social networking website with over 200 Million active users. How does the church engage, minister to, and help people through this social medium? Furthermore, is there a way to convert connections made in Facebook into potential church members?

We tackle the problem with a prototype of application that functions with the overarching concept of “Virtual Outreach over Virtual Church.” Not only do we aim to build an ecology of people helping each other, but by reaching out to people and helping them deal with issues that affect their lives, church ministers and lay leadership can build “social capital” and trust in the digital world. This, in turn, will make their invitations to check out the church family much more appealing. Prospects, thus invited via the Outreach app, will then be routed directly into the church’s Fellowship One database.

Content
Video | Slide deck | Code | OAuth Lib

Application #3: Listee (Team Earth – Expression Engine) – 2nd Party
Developers: Nathan Smith, Jingyi Wang
Description:
This module allows a web designer to easily include F1 data using the ExpressionEngine content management system. The benefit of this is that EE is a very popular CMS for high-end designers, because it's templating language is so intuitive.

Content
Video | Slide deck | Code | OAuth Lib

Application #4: IWANTTOSERVE.COM (Team Water - .NET MVC) – 3rd Party
Developers: Tim Hardy, Tudor Lupan
Description:
We’ve developed a “Needs board” application that allows church members (anyone with a WebLink login) to post needs and search needs to minister to each other. There is a tremendous need for a technical tool that can direct member’s willingness to serve to the valid needs of others. While several tools have attempted to provide this functionality, none have taken advantage of the tried-and-true community self-monitoring patterns established by services such as ebay. We’ve implemented a double opt-in system – the need submitter has to “Accept” a helper’s willingness to help, and the helper has to then “Commit”. Both the submitter and the committed helpers can then rate each other to curb service abuses once the need has been met or the due date expired. It completely leverages WebLink logins for authentication, and it contains a fully functional user profile editor

Content
Video | Slide deck | Code | OAuth Lib

Nick Floyd - Integration Architect

Fellowship One REST API - OAuth Security Update

FTProductDev — Thu, 23 Apr 2009 07:43:00 GMT

NOTE: THIS UPDATE ONLY CONCERNS THE FELLOWSHIP ONE RESTFUL API BETA OAUTH IMPLEMENTATION

Yesterday a minor security threat was discovered in the OAuth protocol.

The OAuth community is aggressively working on the issue and have released an advisory update on this on 4.23.2009 at 12:00 am PST. We have been in contact with them on the details of this issue. After a close look at the threat and considering the risks involved, we have determined that we will not suspend the use of OAuth in our API. Instead, we will immediately implement additional mechanisms to further protect against potential attack:

Shorten the request token life time
Require any 3rd Party application to have a registered callback
Require additional warnings and details on the token authorization pages to clearly explain the intent of the Consumer application

We take all security-related issues seriously. Although the REST API OAuth implementation is only available in a beta environment right now, we want to take mitigating actions.These changes to our OAuth Service Provider implementation will be deployed soon.

We purposely chose OAuth as our primary authentication mechanism because of the security and iron-clad structure it provides. We are even more encouraged by our choice in light of the quick response and reaction from the OAuth community. Since there are thousands of developers and applications behind this protocol, there are thousands of people behind our implementation.

We would like to thank Chris Messina, Eran Hammer-Lahav, and the rest of the OAuth community for being so transparent and quick to respond and collaborate to solve this issue.

Please do not hesitate to contact us directly with any concerns or questions that you may have: api [at] fellowshiptech.com

More information: see OAuth advisories updates

Nick Floyd
Integration Architect

Fellowship One APIs - Past, Present, and Future

FTProductDev — Wed, 25 Feb 2009 22:42:00 GMT

With the up coming Fellowship One RESTful API we wanted to take the some time and look back on our other two APIs and reflect on what we intended them to be and what they actually became. We looked at the their interfaces, authentication, resources, versioning, protocols, logging mechanisms, "debuggability", etc... What we found out was that in the world of "API" nothing ever ends up like you intend.

Fellowship One Data Exchange: A very powerful XML RPC API that was specifically designed to address massive data import and export needs. It's ridged pinpoint interface allow users to build simple data presses, which move large amounts of data between disparate systems. A few years into the product's life we introduced the ability to do synchronous transactions - a decision that completely changed many consumer's usage patterns.

Serendipity stepped in and instantly consumers began to use this brute force application on websites to perform anything from profile updates to seamless login patterns. After seeing how much the community found value in the login metaphor we've published docs and given presentations on the best practices of this approach. We now have 3rd parties writing web applications and hosting web sites that do a myriad of things.

Being a SOAP based .NET web service, consuming Data Exchange required the language to either have a library that constructs SOAP envelopes or that the developer understand that protocol and be able to construct a SOAP message manually.

Another characteristic of this API are the logging and response mechanisms; both were intended to only be used / interpreted by the consuming application. Its authentication is based on simple credential / key maps.

Fellowship One Payment Gateway: A .NET SOAP based web service that gives churches the ability to submit giving / e-commerce transactions. The interesting thing about this service is that it was originally developed for internal consumption only and later opened up to external consumers for book stores, tithe applications, etc... another decision point that changed the way an established API was used.

Payment Gateway answered a changeling question of: "how do I get all of my billing and payments to go through one channel and be able to report on the transactions going through that channel?" Much like Data Exchange, we saw it consumed in ways we couldn't have imagined.

We used credential and signed key authentication for this API.

Fellowship One RESTful API: A REST based web application that uses several open protocols and patterns to provide consumers access to secure resources.

STANDARDS, PROTOCOLS, and PATTERNS - nothing else. Looking back, we could see where their is major value in sticking with something that is "tried and true." If we could use web based patterns and protocols for a web based API we could not only get instant adoption but gain the efficiencies and effectiveness of technologies that "just work."

This next generation of API is, ironically based on foundations that have been in place for years. We chose MVC as the application architecture, OAUTH protocol for Authentication, REST and HTTP 1.1 as the transport. This API should give web developers an tool where all they have to think about is what to do with the resources.

Thank you for partnering with us over the years; we have a lot of fun stuff up ahead and we hope to see you at the Dev track @ DC09!

DC08 RESTful rewind

FTProductDev — Sat, 14 Jun 2008 09:19:00 GMT

A few of you guys wanted the video from the conference on the RESTful API. We decided to go back and condense the presentation to give you a more tangible look @ the new API.

Look for more videos in the upcoming weeks to address questions and thoughts that have been coming our way. Thx guys for the awesome feedback - you guys rock!

Download here

- F1Dev