haveapi 0.28.3 → 0.29.0

data/spec/server/integration_spec.rb

@@ -37,6 +37,19 @@ describe HaveAPI::Server do
             { msg: params.dig(:test, :msg) }
           end
         end
+
+        define_action(:AuthorizeError) do
+          route 'authorize_error'
+          http_method :get
+
+          authorize do
+            raise 'authorize boom'
+          end
+
+          def exec
+            ok!
+          end
+        end
       end
 
       define_resource(:Transfer) do
@@ -143,6 +156,27 @@ describe HaveAPI::Server do
       expect(api_response).not_to be_ok
     end
 
+    it 'routes request-level exceptions through hook' do
+      calls = []
+
+      app.settings.api_server.connect_hook(:request_exception) do |ret, context, exception|
+        calls << [context, exception]
+        ret
+      end
+
+      header 'Accept', 'application/json'
+      get '/v1/tests/authorize_error'
+
+      expect(last_response.status).to eq(500)
+      expect(api_response).not_to be_ok
+      expect(api_response.message).to eq('Server error occurred')
+
+      expect(calls.size).to eq(1)
+      context, exception = calls.first
+      expect(context.action.to_s).to include('AuthorizeError')
+      expect(exception.message).to eq('authorize boom')
+    end
+
     it 'handles CORS preflight OPTIONS' do
       header 'Accept', 'application/json'
       header 'Origin', 'https://example.com'

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: haveapi
 version: !ruby/object:Gem::Version
-  version: 0.28.3
+  version: 0.29.0
 platform: ruby
 authors:
 - Jakub Skokan
@@ -29,14 +29,34 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.28.3
+        version: 0.29.0
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.28.3
+        version: 0.29.0
+- !ruby/object:Gem::Dependency
+  name: i18n
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '1.6'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '2'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '1.6'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '2'
 - !ruby/object:Gem::Dependency
   name: json
   requirement: !ruby/object:Gem::Requirement
@@ -190,12 +210,8 @@ files:
 - LICENSE.txt
 - README.md
 - Rakefile
-- doc/create-client.md
 - doc/hooks.erb
 - doc/index.md
-- doc/json-schema.html
-- doc/protocol.md
-- doc/protocol.png
 - haveapi.gemspec
 - lib/haveapi.rb
 - lib/haveapi/action.rb
@@ -234,6 +250,9 @@ files:
 - lib/haveapi/extensions/base.rb
 - lib/haveapi/extensions/exception_mailer.rb
 - lib/haveapi/hooks.rb
+- lib/haveapi/i18n.rb
+- lib/haveapi/locales/cs.yml
+- lib/haveapi/locales/en.yml
 - lib/haveapi/metadata.rb
 - lib/haveapi/model_adapter.rb
 - lib/haveapi/model_adapters/active_record.rb
@@ -241,6 +260,7 @@ files:
 - lib/haveapi/output_formatter.rb
 - lib/haveapi/output_formatters/base.rb
 - lib/haveapi/output_formatters/json.rb
+- lib/haveapi/parameters/metadata_i18n.rb
 - lib/haveapi/parameters/resource.rb
 - lib/haveapi/parameters/typed.rb
 - lib/haveapi/params.rb
@@ -264,6 +284,7 @@ files:
 - lib/haveapi/spec/mock_action.rb
 - lib/haveapi/spec/spec_methods.rb
 - lib/haveapi/tasks/hooks.rb
+- lib/haveapi/tasks/i18n.rb
 - lib/haveapi/tasks/yard.rb
 - lib/haveapi/types.rb
 - lib/haveapi/validator.rb
@@ -312,7 +333,9 @@ files:
 - spec/documentation_spec.rb
 - spec/envelope_spec.rb
 - spec/extensions/action_exceptions_spec.rb
+- spec/extensions/exception_mailer_spec.rb
 - spec/hooks_spec.rb
+- spec/i18n_spec.rb
 - spec/model_adapters/active_record_spec.rb
 - spec/parameters/typed_spec.rb
 - spec/params_spec.rb

data/doc/create-client.md

@@ -1,107 +0,0 @@
-# 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`.
-
-## Blocking actions
-Useful for APIs with long-running actions. Clients can check state of such actions
-using resource `ActionState`. Because this resource is automatically present in all
-APIs that use blocking actions, client libraries expose this resource to the developer
-just as any other resource in the API.
-
-However, you may wish to integrate it in your client and provide ways for the action
-call to block/accept callbacks.