Hi: Where do you all think the web service client code (for a REST service) access fit in a Rails App? Models are what Controllers call and should probably do so now also even though its Non-Active Record. However, Models use the web service REST Access code to get XML and parse it to give ActiveRecord style responses to controller. Where should the Net:Http connection style requests be made-- in lib or initializer requiring lib or as create as a new plugin? Where does the parsing of XML code happen-- in Model Itself? Is the Rails Helper directory directed more towards views helpful here? Getting it done could be easy to do everything in controller. However, want to make it more well designed and scaleable from future perspective. Hence, above code layout questions. Please advise based on experiences. Thanks in Advance. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Curtis Schofield
2010-Feb-28 19:29 UTC
Re: Web service client code layout -- standard practice
You might like httparty for this (instead of Net:Http) I think a good place - if you are only doing it it one place - is the model you use it in - with a test around that model. If you are doing more than that and you are building a tool for this then the lib directory. On Sun, Feb 28, 2010 at 7:59 AM, Smart RoR <lists-fsXkhYbjdPsEEoCn2XhGlw@public.gmane.org> wrote:> Hi: > > Where do you all think the web service client code (for a REST service) > access fit in a Rails App? > Models are what Controllers call and should probably do so now also even > though its Non-Active Record. > > However, Models use the web service REST Access code to get XML and > parse it to give ActiveRecord style responses to controller. > > Where should the Net:Http connection style requests be made-- > in lib or initializer requiring lib or as create as a new plugin? > > Where does the parsing of XML code happen-- in Model Itself? > > Is the Rails Helper directory directed more towards views helpful here? > > > Getting it done could be easy to do everything in controller. However, > want to make it more well designed and scaleable from future > perspective. Hence, above code layout questions. > > > Please advise based on experiences. > > Thanks in Advance. > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org<rubyonrails-talk%2Bunsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Curtis Schofield wrote:> You might like > > httparty for this (instead of Net:Http) > > I think a good place - if you are only doing it it one place - is the > model > you use it > in - with a test around that model. > > If you are doing more than that and you are building a tool for this > then > the lib directory.Thank you. Will see the mentioned gem. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I guess ActiveResource is restrictive if you don''t have control on the WebService API. Net::Http is most flexible but no parsing done for you. Httparty seems nice. It uses Crack gem for XML parsing, that is better than Rexml and Hpricot in terms of parsing I think. Of course, libxml is the fastest but this good too. In the end, use depending on what works for you based on your requirements. -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
Smart RoR wrote:> I guess ActiveResource is restrictive if you don''t have control on the > WebService API. > > Net::Http is most flexible but no parsing done for you. > > Httparty seems nice. It uses Crack gem for XML parsing, that is better > than Rexml and Hpricot in terms of parsing I think. Of course, libxml is > the fastest but this good too. > > In the end, use depending on what works for you based on your > requirements.And yes, Httparty uses Net:Http under the hood, so you know it is reliable for the basic calls....:-) -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.