haveapi 0.21.1 → 0.22.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0e72ad9fd9ee5a7d0ada6b5985e28f51d6fe65423b290aae824f6ff55a067145
-  data.tar.gz: c6c35096b29c02199c3dd4ae46d2ee8ec6920e2f5d5436596e4cde1a133c80cf
+  metadata.gz: 3d886505aa1e12970c014a30cd9b51aecb7b97218c62d4b86069c397d2979a69
+  data.tar.gz: 4c33b3e2c9fd695737163e00bb1dfe04799356a06591a8cecb6b1d27e675975b
 SHA512:
-  metadata.gz: 722c8af5849aef6fe6dbbf48d53bb159c66a9dcd4decafcc4ba20a5f6fee441dbe0eb2d08a2f91283dd900869e1e36632281fcabc038a0ad8ed83dbc9255e053
-  data.tar.gz: b26b675cb2ce63c3d7f2723f3084bb7e7289d4ee896dfbdcf875ed841adedc9feb991b3ee76715586fc79d8b21657e537c446e2284aab24dd94361dfbbd78383
+  metadata.gz: 41837c1ac3eba812bf548cc00edb86f7ff7d9b6af63acbf07ba475027a099300f7a7c2109682e2108dd501b8a51d381625b1f308bee4b580ee49644894d97b57
+  data.tar.gz: 6b1b487e12e28912230a37c327de0863056931203574e5fd0d35096c61d3dbf5018af7846d2cee9116c53f442adb799497f1b803b9609599076b0fd065287f95

data/haveapi.gemspec

@@ -16,7 +16,7 @@ Gem::Specification.new do |s|
 
   s.add_runtime_dependency 'activesupport', '>= 7.1'
   s.add_runtime_dependency 'github-markdown'
-  s.add_runtime_dependency 'haveapi-client', '~> 0.21.1'
+  s.add_runtime_dependency 'haveapi-client', '~> 0.22.1'
   s.add_runtime_dependency 'json'
   s.add_runtime_dependency 'mail'
   s.add_runtime_dependency 'nesty', '~> 1.0'

data/lib/haveapi/client_examples/ruby_client.rb

@@ -80,7 +80,7 @@ module HaveAPI::ClientExamples
         out << "# reply is an instance of HaveAPI::Client::ResourceInstance\n"
 
         (sample[:response] || {}).each do |pn, pv|
-          param = action[:output][:parameters][k]
+          param = action[:output][:parameters][pn]
 
           if param[:type] == 'Resource'
             out << "# reply.#{pn} = HaveAPI::Client::ResourceInstance("

data/lib/haveapi/version.rb

@@ -1,4 +1,4 @@
 module HaveAPI
   PROTOCOL_VERSION = '2.0'.freeze
-  VERSION = '0.21.1'.freeze
+  VERSION = '0.22.1'.freeze
 end

data/shell.nix

@@ -6,7 +6,7 @@ in stdenv.mkDerivation rec {
   name = "haveapi";
 
   buildInputs = with pkgs;[
-    ruby
+    ruby_3_2
     git
     openssl
   ];

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: haveapi
 version: !ruby/object:Gem::Version
-  version: 0.21.1
+  version: 0.22.1
 platform: ruby
 authors:
 - Jakub Skokan
@@ -44,14 +44,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.21.1
+        version: 0.22.1
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.21.1
+        version: 0.22.1
 - !ruby/object:Gem::Dependency
   name: json
   requirement: !ruby/object:Gem::Requirement
@@ -204,13 +204,8 @@ files:
 - LICENSE.txt
 - README.md
 - Rakefile
-- doc/Hooks.md
-- 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

data/doc/Hooks.md

@@ -1,81 +0,0 @@
-
-# Hooks
-
-##HaveAPI::Server
-	
-### post_authenticated
-<table>
-	<tr>
-		<td style="vertical-align: top;">Description:</td>
-		<td>Called after the user was authenticated</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Context:</td>
-		<td>current</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Arguments:</td>
-		<td><dl><dt>current_user</dt><dd>object returned by the authentication backend</dd></dl></td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Initial value:</td>
-		<td>none</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Return value:</td>
-		<td>none</td>
-	</tr>
-</table>
-	
-### description_exception
-<table>
-	<tr>
-		<td style="vertical-align: top;">Description:</td>
-		<td>Called when an exception occurs when building self-description</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Context:</td>
-		<td>current</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Arguments:</td>
-		<td><dl><dt>context</dt><dd>HaveAPI::Context</dd><dt>exception</dt><dd>exception instance</dd></dl></td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Initial value:</td>
-		<td>none</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Return value:</td>
-		<td><dl><dt>http_status</dt><dd>HTTP status code to send to client</dd><dt>message</dt><dd>error message sent to the client</dd></dl></td>
-	</tr>
-</table>
-	
-
-##HaveAPI::Action
-	
-### exec_exception
-<table>
-	<tr>
-		<td style="vertical-align: top;">Description:</td>
-		<td>Called when unhandled exceptions occurs during Action.exec</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Context:</td>
-		<td>current</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Arguments:</td>
-		<td><dl><dt>action</dt><dd>HaveAPI::Action instance</dd><dt>exception</dt><dd>exception instance</dd></dl></td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Initial value:</td>
-		<td>none</td>
-	</tr>
-	<tr>
-		<td style="vertical-align: top;">Return value:</td>
-		<td><dl><dt>status</dt><dd>true or false, indicating whether error should be reported</dd><dt>message</dt><dd>error message sent to the user</dd></dl></td>
-	</tr>
-</table>
-	
-

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.