<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"><https://github.com/nesquena/rabl></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>