I agree with Warren; I'd build a client gem which is as simple as possible, you can have fixed model classes but keep them poro. Make your http library configurable (Faraday is an easy war to do that) as net/http is pretty sucky but not everyone can use the more performant libraries. It's nice if you can make your parser configurable here too (multijson if you're using json ;)) again to allow your users to choose between performance and dependency trade offs.
I've often seen people using Faraday and things like hashie to good effect here, just providing solid object representations from your api data. Then if you want to you can provide an engine/railties aware gem on top of this that uses your client gem. When providing an api client you really want to make as little assumptions as possible if you want to drive adoption of your service. I'm assuming this api has been built for public consumption, but even if it's internal this advice still applies… You don't know what you might want to use your api for in the future, assuming less open's your options. Jon Rowe ----------------------------- m...@jonrowe.co.uk jonrowe.co.uk On Wednesday, 5 June 2013 at 10:40, Warren Seen wrote: > I'm going to be the contrarian and say that I'd be put off using an API if > the client gem was an engine. > > Sure, provide a reference implementation app, but please don't dictate to me > as a consumer how I should structure my models and controllers. What if I'm > not using a relational DB, or if I want to use Sinatra? > > I would stick to providing a client gem consisting of plain ruby objects > wrapping calls to your API, so eg wrappers around httparty or faraday, but > not much else. Make the rest available but optional. > > Cheers, > > Warren. > > On 05/06/2013, at 9:04 AM, Sebastian Porto <sebaspo...@gmail.com > (mailto:sebaspo...@gmail.com)> wrote: > > > Totally agree, an engine is what you want. > > http://guides.rubyonrails.org/engines.html > > > <compose-unknown-contact.jpg> > > > Clifford Heath (mailto:clifford.he...@gmail.com) > > > 4 June 2013 11:48 PM > > > > > > > > > Fabio, > > > > > > That sounds like a textbook case for a Rails engine. > > > > > > Clifford Heath. > > > > > > > > > <postbox-contact.jpg> > > > Fabio Vilela (mailto:fbvil...@gmail.com) > > > 4 June 2013 11:29 PM > > > > > > > > > Hi guys, > > > > > > some noob question just so you don't get bored here... I've recently > > > built a restful api and a few apps were born to consume it. we picked up > > > a few things in common that I'd like to put in this gem/project: > > > -- migration files, suggesting a db structure ( we have had the > > > experience where devs interpreted our api differently ) > > > -- Model classes( thinking about Active Resource + Faraday for some > > > other operations, HTTParty maybe) I really want to write some good > > > documentation in the models > > > -- routes + controller to process webhooks > > > -- some rake tasks and instructions to setup cronjobs... > > > > > > what should I do? gem or project that people would fork and use as a > > > starting point? > > > maybe write some generators? > > > > > > cheers guys. > > > Fabz > > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Ruby or Rails Oceania" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to rails-oceania+unsubscr...@googlegroups.com > > > (mailto:rails-oceania+unsubscr...@googlegroups.com). > > > To post to this group, send email to rails-oceania@googlegroups.com > > > (mailto:rails-oceania@googlegroups.com). > > > Visit this group at http://groups.google.com/group/rails-oceania?hl=en. > > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby or Rails Oceania" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to rails-oceania+unsubscr...@googlegroups.com > > (mailto:rails-oceania+unsubscr...@googlegroups.com). > > To post to this group, send email to rails-oceania@googlegroups.com > > (mailto:rails-oceania@googlegroups.com). > > Visit this group at http://groups.google.com/group/rails-oceania?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rails-oceania+unsubscr...@googlegroups.com > (mailto:rails-oceania+unsubscr...@googlegroups.com). > To post to this group, send email to rails-oceania@googlegroups.com > (mailto:rails-oceania@googlegroups.com). > Visit this group at http://groups.google.com/group/rails-oceania?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceania+unsubscr...@googlegroups.com. To post to this group, send email to rails-oceania@googlegroups.com. Visit this group at http://groups.google.com/group/rails-oceania?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
