Service authors subclass this to produce the body of their service interface implementation. It defines a series of methods that must be implemented in order to service requests.

A Hoodoo::Services::Implementation subclass is selected by the platform middleware because a Hoodoo::Services::Interface subclass tells it about the implementation class through the Hoodoo::Services::Interface.interface DSL; the interface class is referenced from an Hoodoo::Services::Service subclass through the Hoodoo::Services::Service.comprised_of DSL; and the application class is run by Rack by being passed to a call to run in config.ru.

Methods
C
D
L
S
U
V
Instance Public methods
create( context )

Implement a “create” action (store one new resource instance).

context

Hoodoo::Services::Context instance describing authorised session information, inbound request information and holding the response object that the service updates with the results of its processing of this action.

# File lib/hoodoo/services/services/implementation.rb, line 64
def create( context )
  raise "Hoodoo::Services::Implementation subclasses must implement 'create'"
end
delete( context )

Implement a “delete” action (delete one existing resource instance).

context

Hoodoo::Services::Context instance describing authorised session information, inbound request information and holding the response object that the service updates with the results of its processing of this action.

# File lib/hoodoo/services/services/implementation.rb, line 86
def delete( context )
  raise "Hoodoo::Services::Implementation subclasses must implement 'delete'"
end
list( context )

Implement a “list” action (paginated, sorted list of resources).

context

Hoodoo::Services::Context instance describing authorised session information, inbound request information and holding the response object that the service updates with the results of its processing of this action.

# File lib/hoodoo/services/services/implementation.rb, line 42
def list( context )
  raise "Hoodoo::Services::Implementation subclasses must implement 'list'"
end
show( context )

Implement a “show” action (represent one existing resource instance).

context

Hoodoo::Services::Context instance describing authorised session information, inbound request information and holding the response object that the service updates with the results of its processing of this action.

# File lib/hoodoo/services/services/implementation.rb, line 53
def show( context )
  raise "Hoodoo::Services::Implementation subclasses must implement 'show'"
end
update( context )

Implement a “update” action (modify one existing resource instance).

context

Hoodoo::Services::Context instance describing authorised session information, inbound request information and holding the response object that the service updates with the results of its processing of this action.

# File lib/hoodoo/services/services/implementation.rb, line 75
def update( context )
  raise "Hoodoo::Services::Implementation subclasses must implement 'update'"
end
verify( context, action )

Optional verification to allow or deny authorisation for a particular action on a call-by-call basis.

The middleware calls this method if a session (Hoodoo::Services::Session) has associated permissions (Hoodoo::Services::Permissions) which say that the resource's implementation should be asked via constant (Hoodoo::Services::Permissions::ASK).

context

Hoodoo::Services::Context instance as for action methods such as show, list and so forth.

action

The action that the caller is trying to perform, as a Symbol from the list in Hoodoo::Services::Middleware::ALLOWED_ACTIONS.

Your implementation MUST return either Hoodoo::Services::Permissions::ALLOW, to allow the action, or Hoodoo::Services::Permissions::DENY, to block the action.

  • If a session's permissions indicate that a resource endpoint should be asked, but that interface does not define its own verify method, then the default implementation herein will deny the request.

  • If a buggy verification method returns an unexpected value, the middleware will ignore it and again deny the request.

Whether or not any of your implementations ever need to write a custom verification method will depend entirely upon your API, whether or not it has a meaningful definition of per-request assessment to allow or deny access and whether or not any sessions can exist with an 'ask' permission inside in the first place. If using the Hoodoo authorisation and authentication mechanism, this would come down to whether or not any Hoodoo::Data::Resources::Caller instances existed with the relevant permission value defined somewhere inside.

# File lib/hoodoo/services/services/implementation.rb, line 126
def verify( context, action )
  return Hoodoo::Services::Permissions::DENY
end