Issue311 improve hook searching

[steniobhz]

Documentation for the Hook Search API (Listeners and Routes)

Available Endpoints

1. Search Listeners

• Endpoint: /registrations/listeners
• HTTP Method: GET
• Description: Searches for all Listeners whose destination field contains the provided query string in the q parameter.

2. Search Routes

• Endpoint: /registrations/routes
• HTTP Method: GET
• Description: Searches for all Routes whose destination field contains the provided query string in the q parameter.

Query Parameter

Both endpoints support the q query parameter, which is used to filter the search results.

• q: A string to search for within the destination field of Listeners or Routes.

Example Request:
GET /registrations/listeners?q=myDestination
GET /registrations/routes?q=myDestination

Response Structure
Example Response - Searching for Listeners:

{
    "listeners": [
        "listener1",
        "listener2",
        "listener3"
    ]
}

Example Response - Searching for Routes:

{
    "routes": [
        "route1",
        "route2",
        "route3"
    ]
}

Key Features

1. Separate Endpoints for Listeners and Routes: The API provides distinct endpoints for Listeners and Routes searches, ensuring optimized search results based on specific hook types.

2. String-Based Search: The API looks for matches in the destination field of both Listeners and Routes. It searches for any substring match rather than an exact match, making the search more flexible.

3. Optimized Search Logic: The API uses efficient search mechanisms internally to quickly find results across registered listeners or routes, reducing response time even with large datasets.

Example Workflow

1. A client wants to find all Listeners with a destination that contains the string "myDestination". They make the following request:
   GET /registrations/listeners?q=myDestination

2. The API returns a JSON object containing the identifiers of matching Listeners:

{
    "listeners": [
        "listener1",
        "listener2"
    ]
}

[mcweba]

As discussed on the phone, you should also add some integration tests in the gateleen-test module. Where is the documentation of this new API feature?

[codecov]

Codecov Report

Attention: Patch coverage is 90.47619% with 4 lines in your changes missing coverage. Please review.

Project coverage is 49.08%. Comparing base (45f39c1) to head (9956eba).
Report is 23 commits behind head on develop.

Files with missing lines	Patch %	Lines
.../java/org/swisspush/gateleen/hook/HookHandler.java	89.74%	1 Missing and 3 partials ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #613      +/-   ##
=============================================
+ Coverage      48.44%   49.08%   +0.63%     
- Complexity      1862     1907      +45     
=============================================
  Files            238      238              
  Lines          11953    12049      +96     
  Branches        1261     1276      +15     
=============================================
+ Hits            5791     5914     +123     
+ Misses          5659     5626      -33     
- Partials         503      509       +6     

Flag	Coverage Δ
	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mcweba]

There seems to be an issue in the implementation of route searching. When listing the routes with

GET /playground/server/hooks/v1/registrations/routes

you get the following response

{
    "routes": [
        "+playground+server+destination1+_hooks+routes+http+myhook54"
    ]
}

However when you add the search query parameter like this

GET /playground/server/hooks/v1/registrations/routes?q=r1

you get the following response

{
    "routes": [
        "/playground/server/destination1"
    ]
}

The response should still be the same. This is the case for listeners hooks but not for route hooks.