<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 07/09/12 12:24 PM, Dmitri Dolguikh
      wrote:<br>
    </div>
    <blockquote cite="mid:5049D954.4080506@redhat.com" type="cite">
      <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 06/09/12 05:17 PM, Martyn Taylor
        wrote:<br>
      </div>
      <blockquote cite="mid:5048CC91.50406@redhat.com" type="cite">On
        09/06/2012 04:19 PM, Hugh Brock wrote: <br>
        <blockquote type="cite">On Thu, Sep 06, 2012 at 04:06:14PM
          +0200, Ivan Nečas wrote: <br>
          <blockquote type="cite">On 09/06/2012 03:30 PM, Hugh Brock
            wrote: <br>
            <blockquote type="cite">On Wed, Sep 05, 2012 at 04:30:59PM
              +0100, Dmitri Dolguikh wrote: <br>
              <blockquote type="cite">The logic used to access Foreman
                server is spread over several <br>
                classes: a bunch of automatically-generated proxy-type
                classes that <br>
                reside in foreman_api gem, ForemanModel (resides in <br>
                lib/resources/foreman_model.rb), that is a base-class
                for Foreman <br>
                resource classes that reside in app/models/foreman. <br>
                <br>
                Good things first: <br>
                  - app/models/foreman classes are minimal, and clearly
                show what <br>
                attributes are being used. <br>
                  - app/models/foreman classes allow for local
                validation via <br>
                standard ActiveModel validators. <br>
                  - app/models/foreman classes allow for easy
                customization of json <br>
                generation. <br>
                <br>
                <br>
                Things I don't like: <br>
                  - I can't shake the feeling that the approach
                represented in the <br>
                branch is a huge duplication of effort. We are
                replicating <br>
                ActiveResource on every step of the way, and: <br>
                   - ActiveResource's error handling is
                better/consistent (ours is <br>
                minimal and current approach would require us to
                recreate all of <br>
                RestClient's exceptions) <br>
                   - ActiveResource's error parsing is much better
                (we'll have to <br>
                duplicate AR's code to be able to parse remote errors).
                <br>
                   - Pretty much all of ForemanModel is what we'd get
                with <br>
                ActiveResource for free. Keep in mind that custom
                methods are simple <br>
                with ActiveResource. <br>
                  - Foreman uses rabl [1] for json-generation, we
                implemented a <br>
                custom approach. I think rabl is at least worth a look.
                <br>
                  - Apipie in it's current shape promotes code
                duplication. See <br>
                foreman_api classes, domain- and
                architectures-controllers in <br>
                katello. <br>
                <br>
                <br>
                I propose: <br>
                  - It's been close to a couple of years since we looked
                at <br>
                ActiveResource last. I'd like to see where it is now,
                how hard it is <br>
                to use with oauth and non-rails types of resource urls
                these days. <br>
                  - I'd like to evaluate rabl for use in Katello <br>
                  - I'd like to fix code duplication issues in Apipie,
                possibly <br>
                switch it to use ActiveResource instead of RestClient <br>
                <br>
                <br>
                -d <br>
                <br>
                <br>
                [1] <a moz-do-not-send="true"
                  class="moz-txt-link-freetext"
                  href="https://github.com/nesquena/rabl">https://github.com/nesquena/rabl</a>
                <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
                  href="https://github.com/nesquena/rabl">&lt;https://github.com/nesquena/rabl&gt;</a>
                <br>
              </blockquote>
              Absent any knowledge of the actual code I strongly agree
              :). <br>
              <br>
              Seriously, we are using active resource pretty heavily in
              a lot of <br>
              places in Conductor, I would like to see us standardize on
              it to the <br>
              extent we can. <br>
            </blockquote>
          </blockquote>
        </blockquote>
        <br>
        <blockquote type="cite">
          <blockquote type="cite">Good to hear you have real experience
            with that. What king of <br>
            services do you use that for? Rails app, or something
            totally out of <br>
            your control (at least partly:) ? I would like to see the
            actual <br>
            code and ask the people that were working on that about
            their <br>
            experience with that. <br>
            <br>
            -- Ivan <br>
          </blockquote>
          cc-ing aeolus-devel. <br>
          <br>
          Martyn, can you give the folks a run-down on our Active
          Resource usage? <br>
          <br>
          --Hugh <br>
        </blockquote>
        <br>
        Sure, so we are using ActiveResource heavily in 3 of our
        projects; talking to a few different RESTful APIs using both
        OAuth and Basic HTTP Authentication. <br>
        <br>
        There is still no native support for OAuth authentication in the
        latest release of ActiveResource though there are a couple of
        gems that offer this functionality.  oauth-active-resource is
        one.  We extended ActiveResource ourselves to add OAuth
        support.  The code is here: <a moz-do-not-send="true"
          class="moz-txt-link-freetext"
href="https://github.com/aeolusproject/aeolus-image-rubygem/blob/master/lib/aeolus_image/active_resource_oauth_client.rb">https://github.com/aeolusproject/aeolus-image-rubygem/blob/master/lib/aeolus_image/active_resource_oauth_client.rb</a>.
        There are one or two things in that patch that make it specific
        to our usage but should be easy enough to generalise to use for
        any OAuth API. <br>
        <br>
        I've cc'd Matt Wagner who is the original author of the OAuth
        patch.  We could fix the specific bits and pull patch that into
        its own gem so we can easily use it across projects. <br>
        <br>
        Custom urls are partially supported in that you can specify
        resource paths and you can create custom methods see: <a
          moz-do-not-send="true" class="moz-txt-link-freetext"
          href="http://api.rubyonrails.org/classes/ActiveResource/Base.html">http://api.rubyonrails.org/classes/ActiveResource/Base.html</a>. 
        If you are doing something particularly different to generally
        accepted patterns then you might have some issues.  Generally
        I've found that ActiveResource works well out of the box with
        rails applications and most REST APIs.  However sometimes it can
        be frustratingly difficult to customize - though we've yet come
        across an issue yet that we've been unable to get round. <br>
        <br>
        Standardizing our usage of ActiveResource really would consist
        of standardizing our APIs, since all the custom code is
        tailoring ActiveResource to the API it is consuming (Other than
        the OAuth support of course). <br>
        <br>
        You should also get a few of the Foreman benefits in
        ActiveResource too: <br>
        <br>
        Good things first: <br>
        <br>
         - app/models/foreman classes allow for local validation via
        standard ActiveModel validators. <br>
        <br>
        ActiveResource includes the ActiveModel validators see: <a
          moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://api.rubyonrails.org/classes/ActiveResource/Validations.html">http://api.rubyonrails.org/classes/ActiveResource/Validations.html</a>
        <br>
        <br>
         - app/models/foreman classes allow for easy customization of
        json generation. <br>
        <br>
        I've not done this but it should be possible by overriding
        to_json methods. <br>
        <br>
        Feel free to ping me on IRC if you'd like to talk more: my nick
        #martyntaylor on freenode <br>
        a <br>
        Regards <br>
        <br>
        Martyn <br>
      </blockquote>
      <br>
      I spent some time yesterday on looking at how to get
      ActiveResource to interact with a non-Rails based rest service
      that uses OAuth (candlepin). See some of the code at [3].<br>
      <br>
       - Adding OAuth support is pretty trivial, with or without
      oauth-active-resource. I did something similar to
      aeolus_image/active_resource_oauth_client.rb<br>
       - Supporting nested resources is done via specifying resource
      prefix, and then supplying prefix parameters when doing stuff with
      the resource [3].<br>
       - ActiveResource *still* insists on appending of encoding type to
      resource urls. Annoying, but the fix is simple (required for
      non-Rails services).<br>
       - It is possible to specify resource schema [2]. Not sure if
      attributes not specified in the schema will be silently dropped,
      or an exception will be thrown. </blockquote>
    <br>
    Correction:<br>
    Data types are currently *NOT* being used however.<br>
    <br>
    <br>
    <blockquote cite="mid:5049D954.4080506@redhat.com" type="cite"><br>
      <br>
      <br>
      Using ActiveResource for Rails-backed service will only require
      changes to support OAuth, which makes it extrememly attractive (if
      not a no-brainer).<br>
      <br>
      -d  <br>
      <br>
       <br>
      [2]
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a moz-do-not-send="true"
href="http://api.rubyonrails.org/classes/ActiveResource/Base.html#method-c-schema">http://api.rubyonrails.org/classes/ActiveResource/Base.html#method-c-schema</a><br>
      [3]
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <a moz-do-not-send="true" href="https://gist.github.com/3665270">https://gist.github.com/3665270</a><br>
      <br>
    </blockquote>
    <br>
    <br>
  </body>
</html>