apipie / apipie-bindings Goto Github PK

View Code? Open in Web Editor NEW

10.0 10.0 23.0 192 KB

License: MIT License

Ruby 99.66% HTML 0.34%

apipie-bindings's People

Contributors

Stargazers

Watchers

apipie-bindings's Issues

Non-required hash paramt turns required if contains required parameter

      @required = param[:required] || @params.inject(false) { |req, par| req ||= par.required? }

The line above from param.rb should ensure that parameter is required when it contains at least one nested required parameter. This doesn't cover cases when the hash param is not required, but when provided it has to contain some attributes.

We should follow what API docs states

Only one version is cached

Hi,

I'm a new user of apipie-bindings wich work just fine.

I've just had a problem with api versions and cache feature: it seems that only a single version is cached, meaning that using both versions is not possible, even with aggressive cache checking since the checksum depends on both versions (don't change when using another version, at least on Foreman API).

The cache feature should cache all API versions, or be able to distinguish which version has been cached.

Did I miss something ?

please create a tag for 0.0.11 release

It would be nice to have also the latest release tagged, as I'm using git diff with the tags often, to check if anything changed that needs handling in packaging.

support rest-client 1.8

Debian/testing already brings rest-client 1.8.0, so it's highly likely that the next Ubuntu LTS release will bring it, too. In my light tests with hammer, everything worked fine, the only noticable thing is that verify_ssl is on by default.

As Ruby 1.8.7 still has to be supported, this has somehow to be taken care of.

We need more hints when apipie doc is not accessible on the server

json dependency needs to be tightened

There's currently no version restriction for json. It should be >= 1.6.1as the bindings use :symbolize_names.

Following redirects doesn't work with rest-client > 1.8

Interface of the method follow_redirects has been changed since 1.8:
rest-client/rest-client@38afe2c

The change produces following error in apipie-bindings:

ArgumentError (wrong number of arguments (given 2, expected 0)):
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/abstract_response.rb:118:in `follow_redirection'
    /root/hammer/apipie-bindings/lib/apipie_bindings/api.rb:326:in `block in rest_client_call_block'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/request.rb:858:in `process_result'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/request.rb:776:in `block in transmit'
    /usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/net/http.rb:853:in `start'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/request.rb:766:in `transmit'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/request.rb:215:in `execute'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/request.rb:52:in `execute'
    /usr/local/rvm/gems/ruby-2.3.0/gems/rest-client-2.0.0/lib/restclient/resource.rb:51:in `get'
    /root/hammer/apipie-bindings/lib/apipie_bindings/api.rb:313:in `call_client'
    /root/hammer/apipie-bindings/lib/apipie_bindings/api.rb:229:in `http_call'
    /root/hammer/apipie-bindings/lib/apipie_bindings/api.rb:179:in `call_action'
    /root/hammer/apipie-bindings/lib/apipie_bindings/api.rb:174:in `call'
    /root/hammer/apipie-bindings/lib/apipie_bindings/resource.rb:21:in `call'

Sending files in PUT/POST params fails

bindings converts params to JSON which causes the content of the file as a parameter is lost.

oauth >= 5.2 requires ruby >= 2.0 and travis build fails

Gem::InstallError: oauth requires Ruby version >= 2.0.
Installing json 1.8.6
An error occurred while installing oauth (0.5.3), and Bundler cannot continue.
Make sure that `gem install oauth -v '0.5.3'` succeeds before bundling.

gem 'i18n' is no longer needed in the dependences

Can't search for resources with spaces in the names

This is probably more of an issue with the Foreman api, but I couldn't find a place to submit an issue. You cannot use search filters on resources by name parameter if there is a space in the name. Many of the default resources have spaces in the name, so this is problematic.

Bindings hide SSL verification errors when cache is being fetched

When ssl_verify is set to true and verification fails during the cache retrieval, bindings hide that exception and raise "Could not load data from... " advising to check whether the server is running and cache was created. This complicates debugging.

apipie-bindings v0.0.16 not compatible with rest-client 2.x

Once v0.0.16 was released we found that Travis builds were failing with the following in the stack trace.

Failures:

  1) ManageiqForeman::Connection#fetch with 2 hosts fetches 2 hosts
     Failure/Error: PagedResponse.new(@api.resource(resource).action(action).call(filter))

     ArgumentError:
       wrong number of arguments (2 for 0)
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/abstract_response.rb:71:in `return!'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/api.rb:308:in `block in rest_client_call_block'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:592:in `call'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:592:in `process_result'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:504:in `block in transmit'
     # /home/bdunne/.gem/ruby/2.2.4/gems/webmock-1.24.2/lib/webmock/http_lib_adapters/net_http.rb:123:in `start_without_connect'
     # /home/bdunne/.gem/ruby/2.2.4/gems/webmock-1.24.2/lib/webmock/http_lib_adapters/net_http.rb:150:in `start'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:494:in `transmit'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:202:in `execute'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/request.rb:52:in `execute'
     # /home/bdunne/.gem/ruby/2.2.4/gems/rest-client-2.0.0.rc1/lib/restclient/resource.rb:51:in `get'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/api.rb:295:in `call_client'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/api.rb:224:in `http_call'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/api.rb:174:in `call_action'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/api.rb:169:in `call'
     # /home/bdunne/.gem/ruby/2.2.4/gems/apipie-bindings-0.0.16/lib/apipie_bindings/action.rb:14:in `call'
     # ./lib/manageiq_foreman/connection.rb:49:in `fetch'
     # ./spec/connection_spec.rb:16:in `block (4 levels) in <top (required)>'
     # ./spec/connection_spec.rb:20:in `block (5 levels) in <top (required)>'
     # ./spec/spec_helper.rb:20:in `block in with_vcr'
     # /home/bdunne/.gem/ruby/2.2.4/gems/vcr-2.9.3/lib/vcr/util/variable_args_block_caller.rb:9:in `call'
     # /home/bdunne/.gem/ruby/2.2.4/gems/vcr-2.9.3/lib/vcr/util/variable_args_block_caller.rb:9:in `call_block'
     # /home/bdunne/.gem/ruby/2.2.4/gems/vcr-2.9.3/lib/vcr.rb:182:in `use_cassette'
     # ./spec/spec_helper.rb:19:in `with_vcr'
     # ./spec/connection_spec.rb:19:in `block (4 levels) in <top (required)>'

Array of hashes is always evaluated as missing

Parameters having type "array of hashes" with some required field in the inner hash are always evaluated as missing. API calls with such parameters always fail on validation.

For example API action documented as:

param :host, Hash, :required => true, :action_aware => true do
  param :interfaces_attributes, Array, :desc => N_("Host's network interfaces.") do
    param :mac, String, :desc => N_("MAC address of interface."), :required => true
  end
end

always fails, even with parameters:

{
  'host' => {
    'interfaces_attributes' => [
      { 'mac' => '001122334455' }
    ]
  }
}

Travis builds are failing on Ruby 1.9.3

index action returns inconsistent data type

When called on :smart_proxies, it returns an array of results. When called on :config_templates, it returns a hash, with the first key being the name of the resource, then all found resources. It would make sense that the api returns consistent data types.

[{"smart_proxy"=>
   {"name"=>"foreman-test.dal.com",
     "id"=>1,
     "url"=>"https://foreman-test.dal.com:8443",
     "created_at"=>"2016-02-14T09:23:12Z",
     "updated_at"=>"2016-02-14T09:23:12Z"}}]

{"config_templates" => [{"config_template"=>{"name"=>"test", "template"=>"  # This is a Chef managed template\n", "snippet"=>true, "audit_comment"=>nil, "id"=>60}}]}

Log server url in the api calls

API cache not auto reloaded after an API call with an error response

Refreshing the cache is skipped when a http call raises an exception:
https://github.com/Apipie/apipie-bindings/blob/master/lib/apipie_bindings/api.rb#L238-L247

It should be checking the cache even on error responses.

When no uri or cache dir is provided API constructor returns ugly error

 <NoMethodError> undefined method `tr' for nil:NilClass
        /home/mbacovsk/work/theforeman/apipie-bindings/lib/apipie_bindings/api.rb:49:in `initialize'
        /home/mbacovsk/work/theforeman/hammer-cli/lib/hammer_cli/apipie/resource.rb:31:in `new'
        /home/mbacovsk/work/theforeman/hammer-cli/lib/hammer_cli/apipie/resource.rb:31:in `initialize'
        /home/mbacovsk/work/theforeman/hammer-cli/lib/hammer_cli/connection.rb:23:in `new'
        /home/mbacovsk/work/theforeman/hammer-cli/lib/hammer_cli/connection.rb:23:in `create'
        /home/mbacovsk/work/theforeman/hammer-cli/lib/hammer_cli/apipie/resource.rb:91:in `resource'
...

Filter out apidoc content from log

It is slowing down output and has no value for the user

Add support for content-type multipart/form-data

Verify SSL by default

For security reasons we should follow RestClient's defaults and set SSL verification as opt out.

config_template creation is broken

require 'apipie-bindings'

c = ApipieBindings::API.new(username: 'admin', password: 'admin', uri: 'https://192.168.33.66')

puts c.call(:domains, :create, domain: { name: 'thing' } )
puts c.call(:config_templates, :create, config_template: { name: 'thing', template: 'thing' } )

{"domain"=>{"created_at"=>"2016-02-15T20:59:37Z", "dns_id"=>nil, "fullname"=>nil, "hostgroups_count"=>0, "hosts_count"=>0, "id"=>5, "name"=>"thing", "updated_at"=>"2016-02-15T20:59:37Z"}}
/Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/abstract_response.rb:48:in `return!': 422 Unprocessable Entity (RestClient::UnprocessableEntity)
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/request.rb:230:in `process_result'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/request.rb:178:in `block in transmit'
    from /Users/demitri/.rvm/rubies/ruby-2.1.0/lib/ruby/2.1.0/net/http.rb:853:in `start'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/request.rb:172:in `transmit'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/request.rb:64:in `execute'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/request.rb:33:in `execute'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/rest-client-1.6.7/lib/restclient/resource.rb:67:in `post'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/apipie-bindings-0.0.15/lib/apipie_bindings/api.rb:285:in `call_client'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/apipie-bindings-0.0.15/lib/apipie_bindings/api.rb:216:in `http_call'
    from /Users/demitri/.rvm/gems/ruby-2.1.0@mozcookbook_foreman/gems/apipie-bindings-0.0.15/lib/apipie_bindings/api.rb:161:in `call'
    from bin/test.rb:6:in `<main>'

Validing array but checking for hash?

In lib/apipie_bindings/action.rb validate function, we have

if param_description.expected_type == :array
    value.each.with_index do |item, i|
        errors += validate(param_description.params, item, add_to_path(path, param_description.name, i))
    end
end

But when it's calling itself (the validate function), and the first line in that function is:

return [ErrorData.new(:invalid_type, path, 'Hash')] unless values.respond_to?(:keys)

Maybe I'm missing something (sure possible), but isn't that taking a value we're expecting to be an array, and checking against if it's a hash and returning 'it's not a hash!' error, even when its NOT supposed to be a hash? At least, that seems to be what I'm running into; bypassing this validation check and my call works fine.

Error responses are not logged

Responses other than 20X don't appear in logs which makes them difficult to debug.
It would also be handy to log headers sent in the request.

Don't explicitly depend on and require awesome_print, let users opt-in

Currently, apipie bindings has a runtime dependency on awesome_print in the gemspec and requires it in api.rb[1]

AwesomePrint is a great debugging for getting started with apipie-bindings but should be avoided in production because it's not really meant for production. It globally monkey-patches core and library classes on require which can easily break your application when upgrading those classes or have performance degradations[2].

If awesome_print is really needed or required, a developer can modify their application to use it with apipie-bindings by adding gem, 'awesome_print' to the Gemfile without a require value, so it gets required.

And in apipie-bindings, we should remove the explicit dependency in the gemspec so users can opt-in explicitly.

Then, in api.rb we can do something like object.respond_to?(:ai) ? object.ai : object.inspect
Or, we could have a method that checks for the AwesomePrint constant to see if it's loaded so we don't have to use these ternaries all over the place.

Please let me know if I can help do this or review this work. I'm sure there's better ways of doing this, so feel free to do this differently.

Thanks in advance 😎

[1] Calls to .ai (awesome_inspect)

$ git grep -E "\bap\b|\bai\b|\bawesome|\bAwesome"
apipie-bindings.gemspec:  s.add_dependency 'awesome_print'
lib/apipie_bindings/api.rb:require 'awesome_print'
lib/apipie_bindings/api.rb:      log.debug "Global headers: #{headers.ai}"
lib/apipie_bindings/api.rb:      log.debug "Params: #{params.ai}"
lib/apipie_bindings/api.rb:      log.debug "Headers: #{headers.ai}"
lib/apipie_bindings/api.rb:            (e.respond_to?(:response) ? process_data(e.response).ai : e.ai)
lib/apipie_bindings/api.rb:      log.debug "Response: %s" % (options[:reduce_response_log] ? "Received OK" : result.ai)
lib/apipie_bindings/api.rb:      log.debug "Response headers: #{response.headers.ai}" if response.respond_to?(:headers)

[2] Benchmark of Array#grep from stdlib on 2.2.3

Note If your array is larger or passes a block to grep, I'm sure the performance of the monkey patch is even worse.

$ ruby -e "require 'benchmark/ips'; Benchmark.ips { |x| x.report('Regular Array#grep') { methods.grep(/get/) } }"
Calculating -------------------------------------
  Regular Array#grep     1.908k i/100ms
-------------------------------------------------
  Regular Array#grep     20.271k (± 4.1%) i/s -    103.032k

Benchmark of Array#grep monkey patched by awesome_print

$ ruby -e "require 'benchmark/ips'; require 'awesome_print'; Benchmark.ips { |x| x.report('Array#grep with AwesomePrint\'s patch') { methods.grep(/get/) } }"
Calculating -------------------------------------
Array#grep with AwesomePrint's patch
                         1.696k i/100ms
-------------------------------------------------
Array#grep with AwesomePrint's patch
                         17.082k (± 3.2%) i/s -     86.496k

Returned error-codes logged at ERROR level - ow.

I have code that's calling apipie-bindings in a context where getting a specific error in return is 'normal', and expected for the app. I rescue the specific error, and Do The Right Thing for the app.

The problem I've run into is that, by default, apipie-bindings logs all returned errors with a log-level of ERROR before my code hears about it. This results in a...suboptimal user-experience for the application. Getting an error-code back from whatever you're talking to, is not necessarily an ERROR.

I can work around this by setting up a logger, but that's just a workaround. Can we dump returned-error-codes at a level less drastic than ERROR, please?

The specific example I have is this:

  # Given a repository-set and a channel-to-repo info for that channel,
  # enable the correct repository
  def enable_repos(org, prod, repo_set, info)
    puts "Enabling #{info['url']}"

    begin
      @api.resource(:repository_sets).call(:enable,
                                           'organization_id' => org['id'],
                                           'product_id' => prod['id'],
                                           'id' => repo_set['id'],
                                           'basearch' => info['arch'],
                                           'releasever' => info['version']) unless option_dry_run?
    rescue RestClient::Exception  => e
      throw e unless e.http_code == 409
      puts "...already enabled."
    end
  end

and upon execution, this is what I'm seeing:

~ $ myhammer import repository-discovery --csv-channels ~/exports/channels.csv --repository-map ~/channel_data_pretty.json
Enabling /content/dist/rhel/server/6/6Server/x86_64/os/Packages
E, [2014-06-17T19:18:48.717399 #28668] ERROR -- : 409 Conflict
{
"errors" => [
[0] "The repository is already enabled"
],
"displayMessage" => "The repository is already enabled"
}
...already enabled.

api.resource(:hosts)
api.resource(:hosts).call(:index)
api.resource(:hosts).call(:show, :id => 1)

becomes:

api.hosts
api.hosts.index
api.hosts.show(:id => 1)

It is mostly syntactic sugar stolen from the Rails world, would it be useful as a PR here?

apipie / apipie-bindings Goto Github PK

apipie-bindings's People

Contributors

Stargazers

Watchers

Forkers

apipie-bindings's Issues

[1] Calls to .ai (awesome_inspect)

[2] Benchmark of Array#grep from stdlib on 2.2.3

Benchmark of Array#grep monkey patched by awesome_print

Recommend Projects

Recommend Topics

Recommend Org