<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 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 class="moz-txt-link-freetext" href="https://github.com/nesquena/rabl">https://github.com/nesquena/rabl</a>
              <a 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 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 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 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. Data types are being currently used
    however.<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
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 href="https://gist.github.com/3665270">https://gist.github.com/3665270</a><br>
    <br>
  </body>
</html>