API service + client options...

[Fred Wu]

Hi guys,

I'm building a RESTful web service that will be consumed by two clients. To cut down the number of techs/frameworks involved, all three apps will be built in Rails. I'm thinking that I could use Grape for creating the API including versioning, and just use ActiveResource in the clients to consume the service.

Are there any better/cleaner solutions? I've checked out HTTParty (and API_Smith) but seems like ActiveResource is still a bit easier to work with. Any thoughts?

Thanks!
Fred

[ben wiseley]

Hey Fred!

If you have control over all three apps and this api isn't going to be used by an unknown third party I'd really consider going the engine route instead of the API route.  It'll be a lot faster in the long run and be one less server you need running.

I started using Grape on an API but ended up going straight Rails in the end.  Grape's great if you're doing simple stuff but getting it to play nice with things like Devise is pretty hackity-hack.

-ben

Fred

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/Hg2WDp82a9oJ.
To post to this group, send email to rails-...@googlegroups.com.
To unsubscribe from this group, send email to rails-oceani...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.

[Simon Russell]

I haven't had great success with ActiveResource, but I guess if you
tune the APIs to meet its fairly limited abilities, it might work.

I'd say use the gem I made for consuming REST APIs of a particular
design, but it's a bit unfinished :) Did work somewhat nicely in most
situations though.

Simon.

[Gareth Townsend]

Fred,

ActiveResource is pretty good and very easy to work with. One thing you will probably need to do is write your own caching strategy around it, there's no support for http caching headers built in sadly.

When I was at NZX, we ended up writing a read-through cache on our client side as our application was very read heavy. More info here: http://injectisforwizards.com/blog/read-through-caching-of-activeresource/

Cheers,
Gareth Townsend
http://www.garethtownsend.info

[Adam Boas]

Hi Fred,

I'm not really a huge fan of ActiveResource. It should be fine as long as you are not doing anything complicated but you will find yourself battling it if you step outside the box at all. I personally prefer to consume services with RestClient. From memory HTTP cacheing is simple to configure with Rack Cache.

I will give Simon's Resty gem a bit of a plug though, I found it quite handy for basic list/show stuff.

Cheers,

Adam

[Fred Wu]

Thanks guys for the suggestions and comments!

@Ben: I did briefly consider using engines but at the end of day, services make more sense. The service itself isn't a module of the clients, it is almost the foundation of the clients, it warrants to be separated from the clients imo. Thanks for the heads up re Grape, I might skip using it if it doesn't play nicely with the other gems. This morning I just discovered Versionist, which looks like just what I need for API versioning.

@Simon: Anything in particular that you found difficult to do in ActiveResource? I had a look at your Resty gem, it's very nice, though I don't really need the self-discovery feature, so it probably is overkill for me.

@Gareth: Oh, really nice! Thanks for the article! If I do end up using ActiveResource, I'd definitely implement this for caching. :)

@Adam: I have total control of the service as well as the clients consuming it, so I imagine it wouldn't be too big of an issue in terms of working around AR's limitation (I could be wrong). The same question I asked Simon - anything in particular that you found difficult to do in ActiveResource?

Thanks!
Fred

[Pat Allan]

I would say Grape generally plays nicely in my experience, but certainly using it with Devise would be a little tricky, but I'd argue that's more a matter of understanding exactly how Devise does its thing (and that Devise is built with Rails in mind, instead of Rack).

--
Pat

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/lOSRJANwEzMJ.

[Samuel Richardson]

Devise is built with Rails in mind so getting it to work with Grape would be quite difficult. In saying that, Warden which Devise is built off is designed to run on Rack and thus is quite easy to roll with Grape/Sinatra. You'll lose some of the views and other things that Devise provides but it's not hard to roll your own instead.

Samuel Richardson
www.richardson.co.nz | 0405 472 748

[Fred Wu]

Just an update:

I've started building the API service using Darcy Laycock's newly released RocketPants gem: https://github.com/filtersquad/rocket_pants Which works pretty well, but unfortunately using his API Smith (https://github.com/filtersquad/api_smith) as the client isn't as easy as using ActiveResource given the relatively simple RESTful URL structure of the systems.

So, I've now switched to using RocketPants (for versioning and error handling) + ActiveResource + InheritedResources - works pretty well so far. :)

Fred

On Monday, 5 March 2012 04:18:06 UTC+11, Fred Wu wrote:

[Adam Boas]

Hi Fred,

Sorry, forgot to reply to your question earlier. The problems we had with ActiveResource were mostly around situations where the source data structure didn't match perfectly with our local data structures. It became a real pain in the ass transforming it. I actually found it easier to just use RestClient and hydrate the class attributes myself using hand rolled builders. We also had services that didn't easily map 1 to 1 with REST. Presumably if you are in control of both ends then you can avoid this.

Cheers,

Adam Boas

--
You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rails-oceania/-/6bqhWFaUSNMJ.

[Michael Pearson]

Relevant (ht Ryan Bigg): https://github.com/rails/rails/pull/572#commits-ref-ae67a63

Shorter: ActiveResource considered unmaintained & mostly unused, pulled out of Rails source tree in the hopes that somebody will fork/fix it (as was done by with ActionMailer)

--
Michael Pearson

[Mikel Lindsaar]

On 14/03/2012, at 9:22 AM, Michael Pearson wrote:

Shorter: ActiveResource considered unmaintained & mostly unused, pulled out of Rails source tree in the hopes that somebody will fork/fix it (as was done by with ActionMailer)

Actually, just a point of order, this process wasn't done with ActionMailer at all :)

Mikel

[Michael Pearson]

It's entirely possible that I skimmed the comments on the train ;)

I think they were comparing AR as it is now to AM as it was then and hoping that by moving it elsewhere that somebody would come and fix it.

(says the person who spent an hour writing a shim between AM for Rails 2.x and AM for Rails 3.x so he didn't have to convert & individually test over twenty notifiers. I'm not proud.)

-- 

Michael Pearson

[Mikel Lindsaar]

On 14/03/2012, at 10:21 AM, Michael Pearson wrote:

(says the person who spent an hour writing a shim between AM for Rails 2.x and AM for Rails 3.x so he didn't have to convert & individually test over twenty notifiers. I'm not proud.)

I guess now is not the time to say "you could have used the compatibility mode" :)

Mikel