haveapi 0.3.0 → 0.3.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 3eed7a7a97050e343134cb1d9cfd614099a613c6
-  data.tar.gz: 09d4bc3e055b2d385b8e6bdf49140425852b4a6f
+  metadata.gz: 4fa0da1f1b314ff7278f68c3f6388579d963b21c
+  data.tar.gz: 7df0e7f2124286d109535b860e53f64c44a06b1c
 SHA512:
-  metadata.gz: ed8241e6a1e8d65b41fb56671fe421730eaab16a748d8373d4331c06a5b14990e2e4a7b535919524bf655ab8a0ca0f6fccdb4c83932d9ec78ece6caffb7e9397
-  data.tar.gz: 992ef4d404cdd0b07564b6bd9310c59280544a026382ec1a84b753586a8cab2482a293f72b3ea15b55f4dcd487181747b7abf14f2f04b880b057ea7b8bef7272
+  metadata.gz: 945c9596473a913973fc06bc1432a5c8c6cb6b921a780ab420eddea9036b281d81b117aabbaf911e3844c5f0391da728a45e00674a482dcd398ac5e3a02ac961
+  data.tar.gz: dd965f92e0c67a799e053fa9b3f5817e3c1b899127884d81372f3f40872df2751450001d4bfbfc525ed6b1f9d7100dd3f46a1ee78e77ad1ec3e1b7946691a6be

data/.gitignore

@@ -0,0 +1,21 @@
+*.gem
+*.rbc
+.bundle
+.config
+.yardoc
+Gemfile.lock
+InstalledFiles
+_yardoc
+coverage
+lib/bundler/man
+pkg
+rdoc
+spec/reports
+test/tmp
+test/version_tmp
+tmp
+*.bundle
+*.so
+*.o
+*.a
+mkmf.log

data/Gemfile

@@ -0,0 +1,12 @@
+source 'https://rubygems.org'
+
+gem 'activerecord'
+gem 'require_all'
+gem 'json'
+gem 'sinatra'
+gem 'mysql'
+gem 'sinatra-activerecord'
+gem 'rake'
+gem 'rspec'
+gem 'rack-test'
+gem 'railties'

data/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014 Jakub Skokan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -0,0 +1,277 @@
+HaveAPI
+=======
+A framework for creating self-describing APIs in Ruby.
+
+Note: HaveAPI is under heavy development. It is not stable, its interface may change.
+
+## What is a self-describing API?
+A self-describing API responds to HTTP method `OPTIONS` and returns description
+of available resources and their actions. The description contains
+full list of parameters, their labels, text notes, data types, validators
+and example usage.
+
+Clients use the self-description to learn how to communicate with the API,
+which they otherwise know nothing about.
+
+## Main features
+- Creates RESTful APIs
+- Handles network communication, input/output formats and parameters
+  on both server and client, you need only to define resources and actions
+- By writing the code you get the documentation which is available to all clients
+- Auto-generated online HTML documentation
+- Generic interface for clients - one client can be used to access all APIs
+  using this framework
+- Ruby, PHP and JavaScript clients already available
+- A change in the API is immediately reflected in all clients
+- Supports API versioning
+- Ready for ActiveRecord - validators from models are included in the
+  self-description
+
+## Usage
+This text might not be complete or up-to-date, as things still often change.
+Full use of HaveAPI may be seen
+in [vpsadminapi](https://github.com/vpsfreecz/vpsadminapi), which may serve
+as an example of how are things meant to be used.
+
+All resources and actions are represented by classes. They all must be stored
+in a module, whose name is later given to HaveAPI.
+
+HaveAPI then searches all classes in that module and constructs your API.
+
+For the purposes of this document, all resources will be in module `MyAPI`.
+
+### Example
+This is a basic example, it does not show all options and functions.
+
+Let's assume a model:
+
+```ruby
+class User < ActiveRecord::Base
+  validates :login, :full_name, :role, presence: true
+  validates :login, format: {
+      with: /[a-zA-Z\.\-]{3,30}/,
+      message: 'not a valid login'
+  }, uniqueness: true
+  validates :role, inclusion: {
+    in: %w(admin user),
+    message '%{value} is not a valid role'
+  }
+  
+  # An example authentication with plain text password
+  def self.authenticate(username, password)
+    u = User.find_by(login: username)
+
+    if u
+      u if u.password == password
+    end
+  end
+end
+```
+
+Resource user might look like this:
+```ruby
+module MyAPI
+  class User < HaveAPI::Resource
+    # This resource belongs to version 1.
+    # It is also possible to put resource to multiple versions, e.g. [1, 2]
+    version 1
+    
+    # Provide description for this resource
+    desc 'Manage users'
+    
+    # ActiveRecord model to load validators from
+    model ::User
+    
+    # Require authentication, this is the default
+    auth true
+    
+    # Create a named group of shared params, that may be later included
+    # by actions.
+    params(:id) do
+      id :id, label: 'User ID'
+    end
+    
+    params(:common) do
+      string :login, label: 'Login', desc: 'Used for authentication'
+      string :full_name, label: 'Full name'
+      string :role, label: 'User role', desc: 'admin or user'
+    end
+    
+    # Actions
+    # Module HaveAPI::Actions::Default contains helper classes that define
+    # HTTP methods and routes for generic actions.
+    class Index < HaveAPI::Actions::Default::Index
+      desc 'List all users'
+      
+      # There are no input parameters
+      
+      # Output parameters
+      output(:object_list) do
+        use :id
+        use :common
+      end
+      
+      # Determine if current user can use this action.
+      # allow/deny immediately returns from this block.
+      # Default rule is deny.
+      authorize do |u|
+        allow if u.role == 'admin'
+        deny  # deny is implicit, so it may be omitted
+      end
+      
+      # Provide example usage
+      example do
+        request({})
+        response({
+          users: [
+            {
+              id: 1,
+              login: 'myuser',
+              full_name: 'My Very Name'
+            }
+          ]
+        })
+        comment 'Get a list of all users like this'
+      end
+
+      # Helper method returning a query for all users
+      def query
+	::User.all
+      end
+
+      # This method is called if the request has meta[:count] = true
+      def count
+        query.count
+      end
+      
+      # Execute action, return the list
+      def exec
+        query.limit(input[:limit]).offset(input[:offset])
+      end
+    end
+    
+    class Create < HaveAPI::Actions::Default::Create
+      desc 'Create new user'
+      
+      input do
+        use :common
+      end
+      
+      output do
+        use :id
+        use :common
+      end
+      
+      authorize do |u|
+        allow if u.role == 'admin'
+        deny
+      end
+      
+      example do
+        request({
+          user: {
+            login: 'anotherlogin',
+            full_name: 'My Very New Name'
+          }
+        })
+        response({
+          user: {
+            id: 2
+          }
+        })
+        comment 'Create new user like this'
+      end
+      
+      def exec
+        user = ::User.new(input)
+        
+        if user.save
+          ok(user)
+        else
+          error('save failed', user.errors.to_hash)
+        end
+      end
+    end
+  end
+end
+```
+
+### What you get
+From this piece of code, HaveAPI will generate a self-describing API.
+It will contain resource `User` with actions `Index` and `Create`,
+using which you can list existing users and create new ones.
+
+You can use any of the available clients to work with the API.
+
+### Run the example
+```ruby
+api = HaveAPI::Server.new(MyAPI)
+
+# Use HTTP basic auth
+class BasicAuth < HaveAPI::Authentication::Basic::Provider
+  def find_user(request, username, password)
+      User.authenticate(username, password)
+  end
+end
+
+api.use_version(:all)
+api.set_default_version(1)
+api.auth_chain << BasicAuth
+api.mount('/')
+
+api.start!
+```
+
+This should start the application using WEBrick. Check
+[http://localhost:4567](http://localhost:4567).
+
+- `GET /` - a list of API versions
+- `GET /doc` - HaveAPI documentation
+- `GET /v1/` - documentation for version 1
+- `OPTIONS /` - description for the whole API
+- `OPTIONS /v1/` - description for API version 1
+
+and more.
+
+### Run with rackup
+Use the same code as above, only the last line would be
+
+```ruby
+run api.app
+```
+
+## Authentication
+HaveAPI defines an interface for creating authentication providers.
+HTTP basic auth and token providers are built-in.
+
+Authentication options are self-described. A client can choose what authentication
+method it understands and wants to use.
+
+## Authorization
+HaveAPI provides means for authorizing user access to actions. This process
+is not self-described.
+
+If the user is authenticated when requesting self-description, only allowed
+resources, actions and parameters will be returned.
+
+## Available clients
+These clients completely rely on the API description and can be used for all
+APIs that are using HaveAPI.
+
+- Ruby client library and CLI: https://github.com/vpsfreecz/haveapi-client
+- PHP client: https://github.com/vpsfreecz/haveapi-client-php
+- JavaScript client: https://github.com/vpsfreecz/haveapi-client-js
+
+or [create your own client](doc/create-client.md).
+
+## Read more
+ - [Protocol definition](doc/protocol.md)
+ - [How to create a client](doc/create-client.md)
+
+## Contributing
+
+1. Fork it ( https://github.com/vpsfreecz/haveapi/fork )
+2. Create your feature branch (`git checkout -b my-new-feature`)
+3. Commit your changes (`git commit -am 'Add some feature'`)
+4. Push to the branch (`git push origin my-new-feature`)
+5. Create a new Pull Request

data/Rakefile

@@ -0,0 +1,7 @@
+require 'bundler/gem_tasks'
+require 'rspec/core'
+require 'rspec/core/rake_task'
+
+RSpec::Core::RakeTask.new(:spec) do |spec|
+  spec.pattern = FileList['spec/**/*_spec.rb']
+end

data/doc/create-client.md

@@ -0,0 +1,98 @@
+# Client definition
+It is necessary to differentiate between clients for HaveAPI based APIs
+and clients to work with your API instance. This document describes
+the former. If you only want to use your API, you should check a list
+of available clients and pick the one in the right language. Only when
+there isn't a client already available in the language you want, then
+continue reading.
+
+# Design rules
+The client must completely depend on the API description:
+
+ - it has no assumptions and API-specific code,
+ - it does not know any resources, actions and parameters,
+ - everything the client knows must be found out from the API description.
+
+All clients should use a similar paradigm, so that it is possible to use
+clients in different languages in the same way, as far as the language syntax
+allows. Clients bundled with HaveAPI may serve as a model. A client should
+use all the advantages and coding styles of the language it is written
+in (e.g. use objects in object oriented languages).
+
+A model paradigm (in no particular language):
+
+    // Create client instance
+    api = new HaveAPI.Client("https://your.api.tld")
+    
+    // Authenticate
+    api.authenticate("basic", {"user": "yourname", "password": "yourpassword"})
+    
+    // Access resources and actions
+    api.<resource>.<action>( { <parameters> } )
+    api.user.new({"name": "Very Name", "password": "donottellanyone"})
+    api.user.list()
+    api.nested.resource.deep.list()
+    
+    // Pass IDs to resources
+    api.nested(1).resource(2).deep.list()
+    
+    // Object-like access
+    user = api.user.show(1)
+    user.id
+    user.name
+    user.destroy()
+    
+    // Logout
+    api.logout()
+
+# Necessary features to implement
+A client should implement all of the listed features in order to be useful.
+
+## Resource tree
+The client gives access to all listed resources and their actions.
+
+In scripting languages, resources and actions are usually defined as dynamic
+properties/objects/methods, depending on the language.
+
+## Input/output parameters
+Allow sending input parameters and accessing the response.
+
+## Input/output formats
+A client must send appropriate HTTP header `Accept`. As only JSON is by now built-in
+in HaveAPI, it should send `application/json`.
+
+## Authentication
+All authentication methods that are built-in the HaveAPI should be supported
+if possible. The client should choose suitable authentication method
+for its purpose and allow the developer to select the authentication method
+if it makes sense to do so.
+
+It is a good practise to implement authentication methods as plugins,
+so that developers may add custom authentication providers easily.
+
+## Object-like access
+A client must interpret the API response according to action output layout.
+Layouts `object` and `object_list` should be handled as object instances,
+if the language allows it.
+
+Object instances represent the object fetched from the database. Received
+parameters are accessed via object attributes/properties. Actions are defined
+as instance methods. Objects may have associations to other resources which
+must be made available and be easy to access.
+
+# Supplemental features
+Following features are supplemental. It is good to support them,
+but is not necessary.
+
+## Client-side validations
+Client may make use of described validators and validate the input before
+sending it to the API, to lessen the API load and make it more user-friendly.
+
+However, as the input is validated on the server anyway, it does not have
+to be implemented.
+
+## Metadata channel
+Metadata channel is currently used to specify what associated resources should
+be prefetched and whether an object list should contain total number of items.
+
+Metadata is nothing more than a hash in input parameters under key `_meta`.

data/doc/index.md

@@ -0,0 +1,6 @@
+HaveAPI documentation
+=====================
+
+ - [README](doc/readme)
+ - [Protocol definition](doc/protocol.md)
+ - [How to create a client](doc/create-client.md)

data/doc/protocol.md

@@ -0,0 +1,355 @@
+# Protocol definition
+HaveAPI defines the format for the self-description and URLs where the self-description
+can be found.
+
+## Self-description
+The API is self-describing. It documents itself. Clients use the self-description
+to work with the API. The Self-description contains access URLs, HTTP methods,
+input and output parameters and their validators.
+A part of description is also an example usage and text notes.
+
+The API responds to ``OPTIONS /``, which returns description of whole
+API, containing all its versions. To get description only of selected version,
+use e.g. ``OPTIONS /v1/``.
+
+Every action also responds to HTTP method ``OPTIONS``,
+with which you can get description for selected action. To distinguish actions with
+the same URL, use parameter ``?method=HTTP_METHOD``.
+
+Thanks to this ability, API changes immediately reflects in all clients without
+changing a single line of code. A client can also be used on all APIs with compatible
+self-describing format, without any changes at all.
+
+## Envelope
+In addition to output format specified below, every API response
+is wrapped in an envelope.
+The envelope reports if action succeeded or failed, provides return value or error
+messages.
+
+      {
+          "status": true if action succeeded or false if error occured,
+          "response": return value,
+          "message": error message, if status is false,
+          "errors: {
+              "parameter1": ["list", "of", "errors"],
+              "parameter2": ["and", "so", "on"]
+          }
+      }
+
+## Description format
+In this document, the self-description is encoded in JSON. However, it can
+be encoded in any of the supported output formats.
+
+### Version
+Version is described as:
+
+    {
+        "authentication": {
+            ... authentication methods ...
+        },
+        "resources": {
+            ... resources ...
+        },
+	"meta": {
+	    "namespace": "_meta"
+	},
+        "help": "/<version>/"
+    }
+
+See appropriate section for detailed description of each section.
+
+### Authentication
+HaveAPI defines an interface for implementing custom authentication methods.
+HTTP basic and token authentication is built-in.
+
+Authentication methods can be set per API version. They are a part of
+the self-description, but must be understood by the client.
+The client can choose whichever available authentication method he prefers.
+
+#### HTTP basic authentication
+HTTP basic authentication needs no other configuration, only informs about its presence.
+
+    "basic": {}
+
+#### Token authentication
+Token authentication contains a resource ``token``, that is used
+to acquire and revoke token.
+
+Token is acquired by action ``request``. The client provides login and password and gets a token
+that is used afterwards. Token has a validity period, which may also be infinity.
+
+Token can be revoked by calling the ``revoke`` action.
+
+    "token": {
+        "http_header": "<name of HTTP header to transfer token in, by default X-HaveAPI-Auth-Token>",
+        "query_parameter": "<name of query parameter for token, by default auth_token>",
+        "resources": {
+            "actions": {
+                "request": {
+                    ...
+                    "input": {
+                        ...
+                        "parameters": {
+                            "login": ...
+                            "password": ...
+                            "lifetime": ...
+                            "interval": ...
+                        },
+                        ...
+                    },
+                    "output": {
+                        ...
+                        "parameters": {
+                            "token": ...
+                            "valid_to": ...
+                        },
+                        ...
+                    },
+                    ...
+                 }
+                "revoke": ...
+            }
+        }
+    }
+
+The format for ``resources`` section is the same as for any other resource.
+
+### Resources
+Each resource is described as:
+
+    "<resource_name>": {
+        "description": "Some description that explains everything",
+        "actions": {
+            ... actions ...
+        },
+        "resources": {
+            ... nested resources ...
+        }
+    }
+
+### Actions
+Every action is described as:
+
+    "<action_name>": {
+        "auth": true|false,
+        "description": "Describe what this action does",
+        "aliases": ["list", "of", "aliases"],
+        "input":  {
+            "layout": "layout type",
+            "namespace": "namespace name",
+            "parameters": {
+                ... parameters ...
+            }
+        },
+        "output": {
+             "layout": "layout type",
+             "namespace": "namespace name",
+             "parameters": {
+                  ... parameters ...
+              }
+        },
+        "examples": [
+            ... list of examples ...
+        ],
+	"meta": ... metadata ...,
+        "url": "URL for this action",
+        "method": "HTTP method to be used",
+        "help": "URL to get this very description of the action"
+    }
+
+#### Layouts
+Layout type is specified for input/output parameters. Thanks to the layout type,
+clients know how to send the request and how to interpret the response.
+
+Defined layout types:
+
+ - object - mainly the response is to be treated as an instance of a resource
+ - object_list - list of objects
+ - hash - simply a hash of parameters, it is to be treated as such
+ - hash_list - list of hashes
+
+In client libraries, the ``object`` layout output usually results in returning
+an object that represents the instance of the resource. The parameters are defined
+as object properties and the like.
+
+#### Namespace
+All input/output parameters are put in a namespace, which is usually
+the name of the resource.
+
+For example:
+
+    {
+        "user": {
+            ... parameters ...
+        }
+    }
+
+### Parameters
+There are two parameter types.
+
+#### Data types
+The type can be one of:
+
+ - String
+ - Text
+ - Boolean
+ - Integer
+ - Float
+ - Datetime
+
+        "<parameter_name>": {
+            "required": true/false/null,
+            "label": "Label for this parameter",
+            "description": "Describe it's meaning",
+            "type": "<one of the data types>",
+            "choices": a list or a hash of accepted values
+            "validators": ... validators ...,
+            "default": "default value that is used if the parameter is omitted"
+        }
+
+If the choices are in a list, than it is a list of accepted values.
+If the choices are in a hash, the keys of that hash are accepted values,
+values in that hash are to be shown in UI.
+
+#### Resource association
+This is used for associations between resources, e.g. car has a wheel.
+
+    "<parameter_name>": {
+        "required": true/false/null,
+        "label": "Label for this parameter",
+        "description": "Describe it's meaning",
+        "type": "Resource",
+        "resource": ["path", "to", "resource"],
+        "value_id": "<name of a parameter that is used as an id>",
+        "value_label": "<name of a parameter that is used as a value>",
+        "value": {
+            "url": "URL to 'show' action of associated resource",
+            "method": "HTTP method to use",
+            "help": "URL to get the associated resource's 'show' description"
+        },
+        "choices": {
+            "url": "URL to action that returns a list of possible associations",
+            "method": "HTTP method to use",
+            "help": "URL to description of the list action"
+        }
+    }
+
+The _resource_ type also has a different output in action response. It returns
+a hash containing associated resource ID and its label, so that clients
+can show the human-friendly label instead of just an ID.
+
+    "<parameter_name>": {
+        "<value of value_id from description>": <resource id>,
+        "<value of value_label from description>": "<label>"
+    }
+
+### Examples
+Examples are described in a generic way, so that every client can
+render them according to its syntax.
+
+    {
+        "title": "A title",
+        "request": {
+            ... a hash of request parameters ...
+        },
+        "response": {
+            ... a hash of response parameters ...
+        },
+        "comment": "Description of the example"
+    }
+
+### Metadata
+Metadata can be global and per-object. Global metadata are sent once for each
+response, where as per-object are sent with each object that is a part of the
+response.
+
+    {
+        "global": {
+	    "input": ... parameters or null ...,
+	    "output: ... parameters or null ...
+	} or null,
+        
+	"object": {
+	    "input": ... parameters or null ...,
+	    "output: ... parameters or null ...
+	} or null,
+    }
+
+### List API versions
+Send request ``OPTIONS /?describe=versions``. The description format:
+
+    {
+        "versions": [1, 2, 3, ... list of versions],
+        "default": <which version is default>
+    }
+
+### Describe default version
+Send request ``OPTIONS /?describe=default`` the get the description
+of the default version.
+
+### Describe the whole API
+It is possible to get self-description of all versions at once.
+
+Send request ``OPTIONS /``. The description format:
+
+    {
+        "default_version": <which version is default>,
+        "versions": {
+            "default": ... full version self-description ...,
+            "<version>": ... full version self-description,
+             ... all other versions ...
+        }
+    }
+
+## Authorization
+Actions may require different levels of authorization. HaveAPI provides means for
+implementing authorization, but it is not self-described.
+
+If the user is authenticated when requesting self-description, only allowed
+resources/actions/parameters will be returned.
+
+## Input/output formats
+For now, the only supported input format is JSON.
+
+Output format can be chosen by a client. However, no other format than JSON is built-in.
+The output format can be chosen with HTTP header ``Accept``.
+
+## Request
+Action URL and HTTP method the client learns from the self-description.
+
+Example request:
+
+    POST /users HTTP/1.1
+    Content-Type: application/json
+    Accept: application/json
+    Connection: Close
+    
+    {
+        "user": {
+            "login": "mylogin",
+            "name": "Very Name",
+            "role": "admin"
+        }
+    }
+
+## Response
+Clients know how to interpret the response thanks to the layout type they learn
+from the self-description.
+
+Example response to the request above:
+
+    Content-Type: application/json
+    
+    {
+        "status": true,
+        "response": {
+            "user": {
+                "id": 1,
+                "login": "mylogin",
+                "name": "Very Name",
+                "role": "admin"
+            }
+	},
+        "message": null,
+        "errors: null
+    }

data/haveapi.gemspec

@@ -0,0 +1,30 @@
+lib = File.expand_path('../lib', __FILE__)
+$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+require 'haveapi/version'
+
+Gem::Specification.new do |s|
+  s.name        = 'haveapi'
+  s.version     = HaveAPI::VERSION
+  s.date        = '2015-08-13'
+  s.summary     =
+  s.description = 'Framework for creating self-describing APIs'
+  s.authors     = 'Jakub Skokan'
+  s.email       = 'jakub.skokan@vpsfree.cz'
+  s.files       = `git ls-files -z`.split("\x0")
+  s.license     = 'MIT'
+
+  s.required_ruby_version = '~> 2.0'
+
+  s.add_runtime_dependency 'activerecord', '~> 4.1.6'
+  s.add_runtime_dependency 'require_all'
+  s.add_runtime_dependency 'json'
+  s.add_runtime_dependency 'sinatra'
+  s.add_runtime_dependency 'mysql'
+  s.add_runtime_dependency 'sinatra-activerecord'
+  s.add_runtime_dependency 'rake'
+  s.add_runtime_dependency 'github-markdown', '~> 0.6.6'
+
+  s.add_development_dependency 'rspec'
+  s.add_development_dependency 'railties'
+  s.add_development_dependency 'rack-test'
+end

data/lib/haveapi/version.rb

@@ -1,3 +1,3 @@
 module HaveAPI
-  VERSION = '0.3.0'
+  VERSION = '0.3.1'
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: haveapi
 version: !ruby/object:Gem::Version
-  version: 0.3.0
+  version: 0.3.1
 platform: ruby
 authors:
 - Jakub Skokan
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2014-05-15 00:00:00.000000000 Z
+date: 2015-08-13 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -170,6 +170,15 @@ executables: []
 extensions: []
 extra_rdoc_files: []
 files:
+- .gitignore
+- Gemfile
+- LICENSE.txt
+- README.md
+- Rakefile
+- doc/create-client.md
+- doc/index.md
+- doc/protocol.md
+- haveapi.gemspec
 - lib/haveapi.rb
 - lib/haveapi/action.rb
 - lib/haveapi/actions/default.rb
@@ -186,7 +195,6 @@ files:
 - lib/haveapi/example.rb
 - lib/haveapi/extensions/action_exceptions.rb
 - lib/haveapi/extensions/base.rb
-- lib/haveapi/extensions/resource_prefetch.rb
 - lib/haveapi/hooks.rb
 - lib/haveapi/metadata.rb
 - lib/haveapi/model_adapter.rb
@@ -235,7 +243,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.2.2
+rubygems_version: 2.2.5
 signing_key: 
 specification_version: 4
 summary: Framework for creating self-describing APIs

data/lib/haveapi/extensions/resource_prefetch.rb

@@ -1,7 +0,0 @@
-module HaveAPI::Extensions
-  class ResourcePrefetch < Base
-    def self.enabled
-
-    end
-  end
-end