Bug 1125313 - apipie-bindings's api_version designation is inconsistent with apipie-rails's api_version designation
Summary: apipie-bindings's api_version designation is inconsistent with apipie-rails's...
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: API
Version: Unspecified
Hardware: Unspecified
OS: Unspecified
medium vote
Target Milestone: Unspecified
Assignee: Bryan Kearney
QA Contact: Katello QA List
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-31 14:31 UTC by Adam Price
Modified: 2017-01-13 19:55 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2017-01-13 19:55:30 UTC

Attachments (Terms of Use)

Description Adam Price 2014-07-31 14:31:10 UTC
Description of problem:

if i point apipie-bindings to 'http://localhost:3000', it only picks up foreman's apidoc resources, but if i point it to 'http://localhost:3000/' (with trailing slash) it correctly picks up foreman and katello apidoc resources.

Steps to Reproduce:
1. quickest way is to try it out in an irb or pry session

[1] pry(main)> require 'apipie_bindings'
[2] pry(main)> api = ApipieBindings::API.new(:uri => "http://localhost:3000",
                                             :username => "admin",
                                             :password => "changeme")
#<ApipieBindings::API ... >
[3] pry(main)> api.resources
  [ 0] <Resource :template_kinds>,
  [ 1] <Resource :reports>,
  [ 2] <Resource :models>,
  [ 3] <Resource :ptables>,
  [ 4] <Resource :domains>,
  [ 5] <Resource :roles>,
  [ 6] <Resource :fact_values>,
  [ 7] <Resource :smart_proxies>,
  [ 8] <Resource :auth_source_ldaps>,
  [ 9] <Resource :architectures>,
  [10] <Resource :settings>,
  [11] <Resource :dashboard>,
  [12] <Resource :statistics>,
  [13] <Resource :home>,
  [14] <Resource :puppetclasses>,
  [15] <Resource :hostgroups>,
  [16] <Resource :config_templates>,
  [17] <Resource :bookmarks>,
  [18] <Resource :images>,
  [19] <Resource :subnets>,
  [20] <Resource :operatingsystems>,
  [21] <Resource :environments>,
  [22] <Resource :common_parameters>,
  [23] <Resource :media>,
  [24] <Resource :lookup_keys>,
  [25] <Resource :autosign>,
  [26] <Resource :compute_resources>,
  [27] <Resource :usergroups>,
  [28] <Resource :users>,
  [29] <Resource :audits>,
  [30] <Resource :hosts>,
  [31] <Resource :organization_default_info>,
  [32] <Resource :host_collection_packages>,
  [33] <Resource :system_packages>,
  [34] <Resource :about>,
  [35] <Resource :custom_info>,
  [36] <Resource :uebercerts>,
  [37] <Resource :distributors>,
  [38] <Resource :host_collection_errata>
[4] pry(main)> api.resources.size

Expected results:

[4] pry(main)> api.resources.size

Additional info:

not sure if this is an issue with apipie-bindings, or apipie-rails

Comment 1 RHEL Product and Program Management 2014-07-31 14:44:33 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 3 Adam Price 2014-07-31 18:17:44 UTC
it appears that my apipie-bindings cache was causing some confusion along with me not passing enough arguments to apipie-bindings.

$ pry
[1] pry(main)> require 'apipie-bindings'
[2] pry(main)> api = ApipieBindings::API.new(:uri => "http://localhost:3000",
                                             :username => "admin",
                                             :password => "changeme",
                                             :aggressive_cache_checking => true,
                                             :api_version => 2)
#<ApipieBindings::API ... >
[3] pry(main)> api.resources.size

though i would argue that the api_version designation be consistent with apipie-rails. everywhere in the code server-side the api_version is set as 'v1' or 'v2' but in apipie-bindings you set the api_version as 1 or 2 (integers). these should be consistent to avoid confusion.

Comment 4 Dominic Cleal 2014-08-11 16:29:56 UTC
This would be better moved to an upstream bug tracker (probably apipie-bindings itself), as it's not really suitable for QE/product-level tracking.

Comment 5 Bryan Kearney 2017-01-13 19:55:30 UTC
This is an older bug which I do not envision being addressed in the near term. I am closing this out. If you believe doing so is an issue, please feel free to re-open and provide additional business information. Thank you.

Note You need to log in before you can comment on or make changes to this bug.