After browsing through wiki's and such, I do not see any particular
documentation on Fat Free's API.  I'm not necessarily an expert on
Rails, but I'm guessing that you can gather API specifications simply
by browsing controller source code.  I'm I off base assuming that?

I am considering starting a project with Fat Free, and I need to know
that I can make other services and applications interact with my Fat
Free instance.  If someone would be so kind as to point me in the
right direction. I would love to put together some API documentation
and examples to contribute.

My biggest concerns are:
How do I get an exhaustive list of resources that are exposed and
attributes that are available?
Also, is there any documentation that I have simply overlooked which
would provide some clues?

Thanks very much for any assistance.

Hi David,

You're right in that you can gather api specs from reading the controllers.
We do follow the rails conventions of allowing html/json/xml requests to
co-exist and most them are documented in the controllers
e.g.
  # GET /accounts/new
  # GET /accounts/new.json
  # GET /accounts/new.xml
 AJAX

We're just beginning a documentation effort to cover FFCRM more broadly and
would love your input. Head on over to
https://github.com/fatfreecrm/fat_free_crm_guides for the bare bones and
vision of what we're trying to do.

If you're looking for simple token based application authentication to take
place on your api calls then take a look at crm_authologic_api (see
g...@github.com:crossroads/crm_authlogic_api.git) which will help you
authenticate your app. We're currently updating it to work with the most
recent ffcrm master so there may be a few rough edges which we're planning
to smooth out in the next few days.

HTH,

Steve

On Thu, Dec 8, 2011 at 6:04 AM, david.gor...@nusun.us <david.gor...@nusun.us

I'm actually interested in this as well.  How rough are the edges with
crm_authlogic_api?  :)  I'm having trouble getting it to authenticate.
 Basically, I added a "before_filter :require_application" to
accounts_controller, created a key called 'test' and gave it a token, and
when I try the URL "http://myserver/accounts?test=myToken" or
"http://myserver/accounts/1?test=myToken", it bounces back to the login
screen.  I've tried other actions in the accounts controller as well with
no luck.  Am I doing something wrong, or are these the kinks that need to
be worked out?  If possible, could you keep us updated on the progress?  I
follow the commits to master, but I don't want to miss it.  Thanks!

- rob

Hi Rob,

I pushed a couple of changes yesterday (which I think you saw) so hopefully
the plugin is now more stable. We have it working now on our system.

The url you should use is:

http://myserver/accounts?app_key=test

Note that reference to "app_key" which is specified here -
https://github.com/crossroads/crm_authlogic_api/blob/master/app/model...

Also, I missed a note in the documentation to say that you have to turn off
the require_user method. - this means authentication is turned off for
users but on for app calls. For security reasons, you might want to create
a new action for this, because anyone with the token can access the action.
This could also have been the reason for redirecting you to the login
screen (effectively a two-factor authentication!)

skip_before_filter :require_user, :only => :my_action
before_filter :require_application, :only => :my_action

I've updated the README.md documentation to reflect that.

Hope that helps.

Steve

Thanks very much for pointing me in the right direction, Steve.  I
will make it a goal to get a basic PHP app to connect and hopefully I
can share the source, plus doc and/or screencast.

Great work and good luck shining up the API!

On Dec 8, 10:12 pm, Steve Kenworthy <stevey...@gmail.com> wrote:

Thanks, I think that got me a little further.  The problem I'm running into
now is that some of the actions end up wanting @current_user to be set.
 For example, get_accounts in AccountsController calls get_list_of_records
in ApplicationController which looks to the current_user for preferences.
 What do you think is the best way to handle this?  I was thinking about
creating a separate action for the app calls, but that might lead to a lot
of duplicate code.  The other option I was thinking about was creating an
actual user that has the same single_access_token as the one I'm using with
crm_authlogic_api.  Thoughts?  

Hi Rob,

That's a very good point about '@current_user'. It actually looks we never
handled that case, since we were only using crm_authlogic_api to
authenticate some search methods from a different plugin. So we would need
to build support for the create/read/update/delete actions on each
controller. This could be quite a big job because of the current
permissions system.
So to answer your previous question, the edges of crm_authlogic_api are
actually a lot rougher than we thought. Sorry about that!
Creating a new user for each application might be the easiest thing to do
for now, but I think it's a reasonable goal for crm_authlogic_api to
support all API calls.

Regards,
Nathan B

Ah, ok.  Couple more questions..sorry about hijacking the thread.  I can
move this over to the developers group if you'd like.

What would the longer term goal be?  Would each user have their own api
key?  I would imagine this is the only way, otherwise if you're creating
users, for example, you'd have "Created by Application" rather than an
actual user.  This way doesn't actually sound horrible to implement on the
surface, but I could very well by overlooking something.  What are your
thoughts on this?  I wouldn't mind putting forth some time to work on this
functionality if we can hash out a clear game plan.  

If the longer term goal proves to be too much to tackle right now, what do
you think about modifying the crm_authlogic_api plugin to automatically
create the user associated with the app/token being generated?  Again, this
is something I could do, I just wanted to discuss first.  

Thanks,
Rob

Sure, questions are always welcome :) After this message, it might also be
good to try moving the discussion to our new user support forum at UserEcho
<http://ffcrm.userecho.com/>(http://ffcrm.userecho.com/).

Our thoughts for the longer term goals, are to provide full support for
applications that require API access. This would probably mean extending
the permissions system to handle Applications as well as Users. The goal
of FFCRM itself is to stay lightweight, customizable and extensible, so
integrating other applications via the API is really one of the most
important things to get right.

I think modifying the crm_authlogic_api plugin would be a good interim
solution. The longer term goal would probably involve adding a token-based
API to core FFCRM, which will probably be too much to tackle right at this
moment.

Regards,
Nathan B

Yeah, let's run with this in userEcho - I've made a ticket here -
http://ffcrm.userecho.com/topic/86125-/

Rob - for the time being feel free to form crm_authlogic_api and send pull
requests with any improvements.

steve

On Wed, Dec 14, 2011 at 10:23 PM, Nathan Broadbent <nathan....@gmail.com>wrote: