Experience.FellowshipOne.com

OK - there has been some confusion within our church on exactly what this API will and will not do - the non-technical staff and leaders think that this will be the end of needing ANY custom code to interface with F1 data. As an example an option was brought up to move from an in-house MS Exchange server solution to a hosted Google Mail option (cheaper and perception of easier maintenance). However one of the really highly visible projects on the plate right now is to make all F1 people accessible in Outlook in the global address book WITHOUT ANY INTERFACE FROM USERS/STAFF (i.e., no running of a report and dumping it down to something to import).

Someone called F1 tech support and what was conveyed from the conversation is that if we move to Google Apps/Mail then the API can simply sync up F1 people with the Google Contact list AUTOMATICALLY with NO USER INTERVENTION or THIRD PARTY INTERFACE/ENGINE.

I've contested that there will have to be something in between that is driving this - that Google will not make the calls into F1 and that F1 is not pushing to Google.

I've tried to comminicate that this API is a developer interface into F1 and although it will do a lot of cool things it needs something to drive it.

I did not attend the conference so I was looking for a good layman's description of this to pass on and for clarification as to how and who will use this API.

Thanks.

George:
You are correct, the nature of an API is to act as a tool to build applications on.  By itself without anything actively consuming it, it will lay dormant.  Code must be written.  The only thing you can use from the REST API without code is the built-in documentation.

With that, you can have batch processes or jobs that can consume the API without any user intervention - but in that case the batch application is acting as the user.

A PULL API (such as Data Exchange or the REST API) is like a gun - no bullet comes out (data) unless the trigger is pulled (a request).

It sounds like what you're referring to above is more like a PUSH API; much like how the enterprise services for iPhone work. Where email, contacts, etc... can be pushed to the phone from the server.

So, while some Google services have PUSH capabilities (just mentioning that because it seems that it came up in your conversations) you would still need a catcher’s mitt (a receiving application) to put the data into Fellowship One.

Addressing your need for a layman's description to pass on:

How: Check out the videos the developers created based on the apps that were demoed at DC09.  They addressed real ministry needs - I think the Facebook video probably is the best illustration if you we're talking to youth pastors, iServe does a good job for Volunteer leaders, and the Expression Engine video is solid when you're addressing Web developers and even high levelers that are looking for a quick win on their website.

Who: For the REST API, we are hoping everyone, but knowing that you need a static perspective - I would say Churches, 3rd parties, and Fellowship One.  Still not clear? I mean that if anyone wants to share their application with other Fellowship One customers, all they have to do is "share it", and if anyone wants to use shared applications all they have to do is opt-in.   

The API will allow a developer to build / extend features of your web presence and backend processes and allow your church to use features built by others from the community on the REST API.

Thanks Nick - this wil be very helpful to forward on - especially coming from the "horses mouth" (no insult intended!). I am technical and do our development and we had some people who have heard "discussions" that I thought had been misinterpreted and as we looked at going to Google Mail/Apps we were actually looking for the "pull" capabilities to get contacts from F1 into Google contacts (or into Exchange if we stay with that) so that they are accessible in Outlook Address Book. What had been perceieved is that there was something magical in the API that if we had google mail/contacts that it would "automatically" sync without something living in between - which I stated I thought was inaccurate.

The other initial intention is to interface with the web site to allow access directories, etc... - and when it is available link calendars to Events in F1, etc...

We also do have "push" plans - allow members to update some info, schedule buildings/rooms, etc... so that leads me to MY question - will DE eventually go away with the API - and how long until the other aspects other than people info for availability through the API?

Great questions.

#1 Will DE eventually go away? No.  The two APIs have distinct purposes.  Have a read here for more on that.  I will say that enhancements and the like will slow on Data Exchange because we are focusing our efforts on what you guys need now and will need for the future. We've been told by the community and internally: "We want REST!"

#2 How long until we get more resources?  This will be a slightly longer answer.

Since the conference we have focused mainly on the Community, getting consumers online, and rounding out the Portal interfaces for the supporting admin stuff that will allow churches to setup applications opt in / opt out and user key management (the whole "app store" concept is going to rock the way we as developers do church - I am very excited about this one).

Now that we've finalized those pieces we're discussing the introduction of Groups 2.0 login and simplified security.  After that and with the ongoing architecture enhancements we have several different resources that we are planning to introduce into the API.  I hate to give you the arbitrary "soon" but that's really the plan - many right now want to get their "web"bed feet web by doing a single sign-on, which I think is the right direction because once the API knows who you are consuming the resources is simple.

We spent a lot of time on the architecture of this API, realizing that if we build in standards, stuck with protocols (like rfc2616), and stood on solid architecture (REST) the consumer would only have to think about how cool they we're going to make their app.  An added benefit is that it made it much easier for us to open up new resources, features, content types, etc... to the community.

Thanks for the reply. So I guess my 10000 foot question is this - with trying to maintain a best practice of keeping F1 as the database of record, what is the "best practice" recommendation/'suggestion for integrating things that are not available through DE or API such as Event Schedules, Building and Room info, Activities, etc....with web site and/or other 3rd party apps?

As a very basic example - if we have a forward facing event calendar on the web site, how do we keep it synced with what gets put into F1? The only thing I see now is running reports, dumping them somewhere, parsing them, and maintaining a separate DB.

Or am I missing a much bigger piece of the puzzle somewhere?