bubbles-rest-client 0.3.1 → 0.7.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: d85396895955c45173bf56e4f7efb61a841bceb90c0d4f3348f99fcb0271e7a0
-  data.tar.gz: c7147c2c317a496d577a63f19f7fe4a398997b9bb6d8b3084585f7da6f93da3c
+  metadata.gz: 0e98610b1755842e9daf75e52a69e406f76ee3726c5b1d5b7094b519a289a8dd
+  data.tar.gz: eef0efcad84ca786a3e425c3251020f54539015ed199b4ccf00d5aaa7acc8e60
 SHA512:
-  metadata.gz: '076759218897e4bac3955b296fa5a0eabb58fb826c5e51c063da34f39d659f7fa2c61d85e8ae064fa5dd46c88a7d3b33baad513bff1951ea629fa30de2c9091e'
-  data.tar.gz: b84b861758a6bd7b44ae4f4153da1467fb6cd5e69b2846450088b7946af21539efe20d9fb3b80f136aa6f0f40cd6f58e5ca5fab3e2cd6fe2f7af8a75a38e8bb4
+  metadata.gz: d57f7ef6b948deec157e1109e17912c0fb923d4bc21626d6df2a91d4958c7cb0ac60c377507f27b3c142a88d09bc09e6e391f9ec8c9ebbe08566fca5c9ba76ce
+  data.tar.gz: 6649af7c90e05d2260bc7fd51ba26c43693b09f9a1e38df18483f78873f761e7261ab13f7fe615909e5da66a299b13eb1830dee3663e6f7bdc881265e72ab374

data/.github/FUNDING.yml

@@ -0,0 +1 @@
+github: jwir3

data/.gitignore

@@ -43,3 +43,6 @@
 
 # Ignore RubyMine files
 .idea/**
+
+# Ignore Gemfile.lock because this is a gem
+Gemfile.lock

data/.travis.yml

@@ -0,0 +1,7 @@
+language: ruby
+rvm:
+  - 2.6.1
+script: bundle exec rake spec
+branches:
+  only:
+    - master

data/CODE_OF_CONDUCT.md

@@ -0,0 +1,77 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as
+contributors and maintainers of Bubbles pledge to making participation in our
+project and our community a harassment-free experience for everyone,
+regardless of age, body size, disability, ethnicity, sex characteristics,
+gender identity and expression, level of experience, education,
+socio-economic status, nationality, personal appearance, race, religion,
+or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment
+include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community and users
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or
+ advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic
+ address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+ professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable
+behavior and are expected to take appropriate and fair corrective action in
+response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or
+reject comments, commits, code, wiki edits, issues, and other contributions
+that are not aligned to this Code of Conduct, or to ban temporarily or
+permanently any contributor for other behaviors that they deem inappropriate,
+threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces
+when an individual is representing the project or its community. Examples of
+representing a project or community include using an official project e-mail
+address, posting via an official social media account, or acting as an appointed
+representative at an online or offline event. Representation of a project may be
+further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported by contacting Scott Johnson, our project lead, at jaywir3@gmail.com. All
+complaints will be reviewed and investigated and will result in a response that
+is deemed necessary and appropriate to the circumstances. The project leadership
+team is obligated to maintain confidentiality with regard to the reporter of an
+incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good
+faith may face temporary or permanent repercussions as determined by other
+members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
+available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see
+https://www.contributor-covenant.org/faq

data/CONTRIBUTING.md

@@ -0,0 +1,31 @@
+# Contributing to Bubbles
+
+## Introduction
+First off, thanks for looking to contribute to Bubbles! We need people like you
+to help us make the best quality product we possibly can. Regardless of whether
+you're a developer, a designer, a technical writer, a student, or even someone
+just interested in learning more about open source and how to contribute, you're
+welcome here.
+
+## Code of Conduct
+Please take a look at our contributor [Code of Conduct](CODE_OF_CONDUCT.md). We
+take harassment and non-inclusive behavior very seriously and will not tolerate
+bullying in any form.
+
+## Development Process
+Our development process works as follows:
+
+1. Fork this repository to your own local Github account.
+2. Clone your local version of the repository: `git clone git@github.com:<username>/bubbles`.
+3. Create a branch on your local repository: `git checkout -b <username>/#<issue>-<short-description>`.
+4. Make any changes you see fit to fix the issue or add your work.
+5. Verify that tests pass: `bundle install && rake spec`.
+6. If you're adding a new feature, make sure to add tests for the feature.
+7. Commit your changes and push to your fork of the repository.
+8. Submit a pull request to the `master` branch of the original repository.
+9. You will receive a review within 7 days, at which time, you may need to make
+   modifications to your code, or your contribution might be accepted as-is.
+
+## Good First Issues
+You can take a look at our [good first issues](https://github.com/FoamFactory/bubbles/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)
+to check out some issues that might be a good starting point for you.

data/README.md

@@ -1,4 +1,6 @@
 # bubbles
+[![Build Status](https://travis-ci.org/FoamFactory/bubbles.svg?branch=master)](https://travis-ci.org/FoamFactory/bubbles)
+
 A gem for easily defining client REST interfaces in ruby
 
 ## Project Goals
@@ -23,17 +25,6 @@ What this does is allow you to focus on your _handling_ of the REST responses, r
 
 _bubbles_ is a Gem that seeks to provide this same behavior.
 
-## :warning: Limitations
-**Please read this section before using!**
-
-Currently, bubbles has a number of limitations that make it likely not suitable for use in a production environment. Each of these is tracked by an issue on our [issues page](https://github.com/FoamFactory/bubbles/issues).
-
-  - Passing an API key with a request is restricted to using `X-Api-Key` as a header key (#10).
-  - Some request methods (specifically `DELETE`) do not currently allow unauthenticated access. In other words, it is not possible to perform a `DELETE` request on your API without passing an authorization token. (#16)
-  - Not all possible combinations of `has_uri_params`, `authenticated`, and `api_key_required` are tested. In some cases, such as with `GET` requests, there aren't any tests for possible configuration cases that might cause issues when combined. (#12)
-
-If you're interested in working on any of the issues above, please feel free to submit a pull request and a member of our team will review that pull request within a couple of days.
-
 ## Usage
 If you're using Rails, it's suggested to have a `config/initializers/bubbles.rb` configuration file where you can easily configure your endpoints and environments. If you're not using Rails, then you can put this configuration just about anywhere, provided it's executed before where you want to use it.
 
@@ -52,20 +43,19 @@ Bubbles.configure do |config|
     }
   ]
 
-  config.local_environment = {
+  config.environments = [{
     :scheme => 'http',
     :host => '0.0.0.0',
     :port => '1234'
-  }
+  }]
 end
 ```
 
-The `config.endpoints` section is where you configure which endpoints you want to support. The `config.local_environment` defines an environment, or remote configuration, for accessing the endpoint on a specific remote destination.
+The `config.endpoints` section is where you configure which endpoints you want to support. The `config.environments` defines the environments, or remote configurations, for accessing the endpoint on specific remote destinations.
 
 Now, you can use this endpoint with:
 ```ruby
 require 'bubbles'
-
 ...
 
 def version
@@ -73,105 +63,11 @@ def version
 
   # The following will make a GET request to
   # http://0.0.0.0:1234/version and return the result.
-  result = resources.local_environment.version
+  result = resources.environment.version
 
   puts(result)
 end
 ```
 
 ## Detailed Documentation
-There are currently two parts to a bubbles configuration: the _environments_ and the _endpoints_. Bubbles is configured in a _bubbles configuration block_:
-```ruby
-Bubbles.configure do |config|
-...
-end
-```
-
-This configuration block can be run at any time, but is typically set up in the initializer section of an app's startup. If desired, configuration can happen separately. That is, you can initialize environments within your initializer file and then initialize endpoints within another section of the application. Just note that when endpoints are defined, it overwrites _all_ endpoints of a configuration, not just the ones you choose to change.
-
-### Environments
-Three environments are currently available to be set up within bubbles. These are:
-  - `local_environment` : Designed to be used for a local API for development testing.
-  - `staging_environment` : Designed to be used for a remote API for second-stage testing or production-like deployment.
-  - `production_environment` : Designed to be used for a production environment.
-
-While the names are hardcoded, the environments can be used for anything - you could easily use a `local_environment` to store the information for one of your production servers.
-
-#### Configuration of Environments
-Environments are configured as part of the _bubbles configuration block_ and can have the following parameters:
-
-  - `scheme`: The scheme for accessing endpoints on this host. Should be one of `http` or `https`. Defaults to `http`.
-  - `host`: A domain name or IP address for the remote host to access for the environment.  Defaults to `127.0.0.1`.
-  - `port`: The port to use to access the remote host. Defaults to `1234`.
-  - `api_key`: The API key to send along with requests for a given environment, if an API key is required. This is optional, and defaults to `nil`.
-
-You can configure all three environments at once in the _bubbles configuration block_:
-```ruby
-Bubbles.configure do |config|
-  config.local_environment = {
-    :scheme => 'http',
-    :host => '0.0.0.0',
-    :port => '1234'
-  }
-
-  config.staging_environment = {
-    :scheme => 'http',
-    :host => 'stage.api.foamfactory.com',
-    :port => '80'
-  }
-
-  config.production_environment = {
-    :scheme => 'https',
-    :host => 'api.foamfactory.com',
-    :port => '443'
-  }
-end
-```
-
-If you choose a scheme of `http` and leave off the `port` configuration variable, it will default to `80`. Similarly, `https` will default to a port of `443`.
-
-#### Configuration of Endpoints
-Endpoints are the meat and potatoes of REST interaction. By indicating a _method_, _uri_, _body_, and _headers_, you are effectively making a function call on a remote server.
-
-_Endpoints_ are specified as an array of objects within the _bubbles configuration block_:
-
-```ruby
-config.endpoints = [
-  # Individual endpoint definitions go here
-]
-```
-
-When processing each of these endpoint definitions, a method is created on instances of `RestEnvironment` that allows you to call the method in question. For example, an endpoint defined as:
-```ruby
-{
-  :method => :get,
-  :location => :version,
-  :authenticated => false,
-  :api_key_required => false
-}
-```
-
-will create a method on instances of `RestEnvironment` called `version`, which will execute the appropriate REST call (via `RestClient`) and return a `RestClient::Response` object.
-
-Each _endpoint_ object can have the following attributes:
-
-| Name    | Description         | Required? | Default |
-| :---    | :------------------ | :-------: | :-----: |
-| `method`| The HTTP method to use to access the API for this endpoint. Must be one of `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, or `HEAD`. | Yes | N/A |
-| `location`| The path to access the endpoint. This is placed after the `host:port` section to build the URI. It may have URI parameters in the form of `{paramName}`. If a URI parameter is specified within the `location`, a `uri_params` hash will be expected to be passed to the calling method to replace the placeholder values. | Yes | N/A |
-| `name` | The name to give the method created to make this REST call. | No | The value of the `location` parameter, with slashes (`/`) replaced with underscores (`_`). |
-| `authorization` | Whether or not this endpoint requires authentication prior to executing the call. If true, then an `authorization_token` will be added to the method as a parameter to be passed when the method is called. This parameter will be placed in an `Authorization` header when the REST call is executed. | No | `false` |
-| `api_key_required` | Whether or not an API key is required. If `true`, a parameter will be added to the method created to execute the REST API call named `api_key`. The value of this parameter will be set as the value of the `X-Api-Key` header when making the REST API call. | No | `false` |
-| `return_type` | Must be one of: `[full_response, body_as_object, body_as_string]`. This specifies what type of response is expected from the `Endpoint`. A value of `full_response` will return the full `RestClient::Response` object to the client. A value of `body_as_string` will return the `RestClient::Response.body` value as a `String`. A value of `body_as_object` will take the `RestClient::Response.body` parameter and parse it as an `OpenStruct` object, and return the result of this parsing operation. | No | `body_as_string` |
-| `encode_authorization` | Whether the `data` passed as part of the request should be re-encoded as an `Authorization: Basic` header (and Base64 encoded). Typically, this is only used for initial username/password authentication. | No | `false` |
-
-### Examples
-#### GET the version of the software (unauthenticated, no API key required)
-
-#### GET a specific user by id (authentication required)
-
-#### POST a login (i.e. retrieve an authorization token)
-
-#### DELETE a user by id
-
-#### PATCH a user's information by providing a body containing information to update
+For more examples and detailed documentation, please see [the Bubbles GitHub page](http://foamfactory.github.io/bubbles).

data/Rakefile

@@ -1,10 +1,5 @@
 require "bundler/gem_tasks"
-require "rake/testtask"
 
-Rake::TestTask.new(:test) do |t|
-  t.libs << "test"
-  t.libs << "lib"
-  t.test_files = FileList['test/**/*_test.rb']
-end
+Dir.glob('lib/tasks/*.rake').each { |r| load r}
 
-task :default => :test
+task :default => :build

data/bubbles.gemspec

@@ -32,14 +32,15 @@ Gem::Specification.new do |spec|
   spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.add_development_dependency "bundler", "~> 2.0.0"
-  spec.add_development_dependency "rake", "~> 10.0"
+  spec.add_development_dependency "bundler", "~> 2.2.26"
+  spec.add_development_dependency "rake", ">= 12.3.3"
   spec.add_development_dependency "minitest", "~> 5.0"
   spec.add_development_dependency "minitest-reporters", "~> 1.1"
   spec.add_development_dependency "simplecov", "~> 0.16"
   spec.add_development_dependency "webmock", "~> 3.5"
   spec.add_development_dependency "vcr", "~> 3.0"
   spec.add_development_dependency "rspec", "~> 3.8"
+  spec.add_development_dependency "os"
   spec.add_dependency "addressable", "~> 2.5"
   spec.add_dependency "rest-client", "~> 2.0"
-end
+end