Re: [rails-oceania] API service + client options...
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 -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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) On Mon, Mar 12, 2012 at 7:51 AM, Adam Boas adam.b...@gmail.com wrote: 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 On 11/03/2012, at 7:15 PM, Fred Wu wrote: 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: 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 -- 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. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- Michael Pearson -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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 -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
On Wed, Mar 14, 2012 at 10:14 AM, Mikel Lindsaar raasd...@gmail.com wrote: 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 :) 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 -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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 On 11/03/2012, at 7:15 PM, Fred Wu wrote: 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: 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 -- 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. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
[rails-oceania] API service + client options...
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 -- 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-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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. On Mon, Mar 5, 2012 at 08:01, ben wiseley wisel...@gmail.com wrote: 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 On Mon, Mar 5, 2012 at 4:18 AM, Fred Wu ifre...@gmail.com wrote: 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 -- 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-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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/ On 05/03/2012, at 9:07 AM, Simon Russell wrote: 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. On Mon, Mar 5, 2012 at 08:01, ben wiseley wisel...@gmail.com wrote: 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 On Mon, Mar 5, 2012 at 4:18 AM, Fred Wu ifre...@gmail.com wrote: 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 -- 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-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. Cheers, Gareth Townsend http://www.garethtownsend.info -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
Re: [rails-oceania] API service + client options...
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 On 05/03/2012, at 9:22 AM, Gareth Townsend wrote: 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/ On 05/03/2012, at 9:07 AM, Simon Russell wrote: 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. On Mon, Mar 5, 2012 at 08:01, ben wiseley wisel...@gmail.com wrote: 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 On Mon, Mar 5, 2012 at 4:18 AM, Fred Wu ifre...@gmail.com wrote: 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 -- 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-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. Cheers, Gareth Townsend http://www.garethtownsend.info -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en. -- You received this message because you are subscribed to the Google Groups Ruby or Rails Oceania group. To post to this group, send email to rails-oceania@googlegroups.com. To unsubscribe from this group, send email to rails-oceania+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
