[FEAT]: Expose hierarchical resource management APIs in core authorizer and HTTP proxy

[MohamadNazik]

Objective

Once the storage layer is tracking strict resources and their parent hierarchy, the core library needs to officially expose the ability for consuming applications to register or remove those resources, both natively as a Go library and over the REST API.

Requirements

1. Core API (bouncer.Authorizer & bouncer.Store)
   • Expand the main interfaces in authorizer.go (root) by adding:
     • CreateResource(ctx context.Context, resourceID string, name string, parent *string) error
     • DeleteResource(ctx context.Context, resourceID string) error
   • Note: We use *string for parent so we can cleanly serialize/deserialize null JSON values.
2. Internal Service implementation
   • Implement the two new methods inside internal/authorization/service.go.
   • Ensure the IDs are validated and mapped correctly before executing the store operations.
3. HTTP Native Adapter
   • In internal/http/handlers.go, scaffold two new handlers: HandleCreateResource and HandleDeleteResource. Use a new JSON struct for the payload:

     type ResourceRequest struct {
         ResourceID string  `json:"resource_id"`
         Name       string  `json:"name"`
         Parent     *string `json:"parent,omitempty"`
     }

   • In httpmux/routes.go, expose the new REST endpoints using the standard library *http.ServeMux (Go 1.22+ syntax):
     • POST /v1/resources
     • DELETE /v1/resources

Definition of Done

• Applications can use the root bouncer.Authorizer locally to natively register a resource.
• Remote applications can leverage standard HTTP calls to easily register or delete resources with optional parents via the updated REST proxy in httpmux.