RESTful API

[david....@nusun.us]

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.

[Steve Kenworthy]

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 

--
You received this message because you are subscribed to the Google Groups "Fat Free CRM Users" group.
To post to this group, send email to fat-free-...@googlegroups.com.
To unsubscribe from this group, send email to fat-free-crm-us...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fat-free-crm-users?hl=en.

[rob]

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

[Steve Kenworthy]

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/models/application_session.rb#L4

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

[david....@nusun.us]

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:
> 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 tohttps://github.com/fatfreecrm/fat_free_crm_guidesfor 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

[rob]

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?  

[Nathan Broadbent]

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

On Mon, Dec 12, 2011 at 2:17 AM, rob <rob...@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?  

--

You received this message because you are subscribed to the Google Groups "Fat Free CRM Users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/fat-free-crm-users/-/RrSFBQk2s7sJ.

[rob]

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

[Nathan Broadbent]

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

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/).

 

 

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.

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.

 

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.

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

[Steve Kenworthy]

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