On 09/06/2012 04:19 PM, Hugh Brock wrote:
On Thu, Sep 06, 2012 at 04:06:14PM +0200, Ivan Nečas wrote:
On 09/06/2012 03:30 PM, Hugh Brock wrote:
On Wed, Sep 05, 2012 at 04:30:59PM +0100, Dmitri Dolguikh wrote:
The logic used to access Foreman server is spread over several
classes: a bunch of automatically-generated proxy-type classes that
reside in foreman_api gem, ForemanModel (resides in
lib/resources/foreman_model.rb), that is a base-class for Foreman
resource classes that reside in app/models/foreman.
Good things first:
- app/models/foreman classes are minimal, and clearly show what
attributes are being used.
- app/models/foreman classes allow for local validation via
standard ActiveModel validators.
- app/models/foreman classes allow for easy customization of json
generation.
Things I don't like:
- I can't shake the feeling that the approach represented in the
branch is a huge duplication of effort. We are replicating
ActiveResource on every step of the way, and:
- ActiveResource's error handling is better/consistent (ours is
minimal and current approach would require us to recreate all of
RestClient's exceptions)
- ActiveResource's error parsing is much better (we'll have to
duplicate AR's code to be able to parse remote errors).
- Pretty much all of ForemanModel is what we'd get with
ActiveResource for free. Keep in mind that custom methods are simple
with ActiveResource.
- Foreman uses rabl [1] for json-generation, we implemented a
custom approach. I think rabl is at least worth a look.
- Apipie in it's current shape promotes code duplication. See
foreman_api classes, domain- and architectures-controllers in
katello.
I propose:
- It's been close to a couple of years since we looked at
ActiveResource last. I'd like to see where it is now, how hard it is
to use with oauth and non-rails types of resource urls these days.
- I'd like to evaluate rabl for use in Katello
- I'd like to fix code duplication issues in Apipie, possibly
switch it to use ActiveResource instead of RestClient
-d
[1] https://github.com/nesquena/rabl <https://github.com/nesquena/rabl>
Absent any knowledge of the actual code I strongly agree :).
Seriously, we are using active resource pretty heavily in a lot of
places in Conductor, I would like to see us standardize on it to the
extent we can.
Good to hear you have real experience with that. What king of
services do you use that for? Rails app, or something totally out of
your control (at least partly:) ? I would like to see the actual
code and ask the people that were working on that about their
experience with that.
-- Ivan
cc-ing aeolus-devel.
Martyn, can you give the folks a run-down on our Active Resource usage?
--Hugh
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.
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:
https://github.com/aeolusproject/aeolus-image-rubygem/blob/master/lib/aeolus_image/active_resource_oauth_client.rb.
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.
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.
Custom urls are partially supported in that you can specify resource
paths and you can create custom methods see:
http://api.rubyonrails.org/classes/ActiveResource/Base.html. 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.
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).
You should also get a few of the Foreman benefits in ActiveResource too:
Good things first:
- app/models/foreman classes allow for local validation via standard
ActiveModel validators.
ActiveResource includes the ActiveModel validators see:
http://api.rubyonrails.org/classes/ActiveResource/Validations.html
- app/models/foreman classes allow for easy customization of json generation.
I've not done this but it should be possible by overriding to_json methods.
Feel free to ping me on IRC if you'd like to talk more: my nick
#martyntaylor on freenode
Regards
Martyn
