Management Rules Endpoint

Management Add Rule Endpoint

Endpoint: Management Add Rule

Method: POST

RESPONSES:
  • 200: A new rule successfully added to the Redirect Rule database
  • 400: Something went wrong during adding the new rule. Check the error which specifies which check it failed

The Add Rule endpoint provides the ability to create/add new rule to the Redirect Rule database. While creating the new Redirect Rule it checks if the rule already exists. If it does a 404 is returned. If the Redirect Rule is new then it will be added to the database and a serialized JSON of the new Redirect Rule instance will be returned.

Management Delete Rule Endpoint

Endpoint: Management Delete Rule

Method: POST

RESPONSES:
  • 200: A Redirect Rule with that id has been deleted successfully
  • 404: A Redirect Rule with that id does NOT exist

The Delete Rule endpoint provides the ability to delete a RedirectRule from the database. It will not take effect for the Hyperscan database. That must be recompiled. The endpoint takes one argument which is the id of the Redirect Rule. If the rule is found it’s delete() method will be executed. The delete is custom and it will delete Domain Rules, Path Rules and Destination Rules if they are not used by any other Redirect Rule. For more insights on the topic take a look at delete_redirect_rule() function. If no Redirect Rule with the given id exists then a 404 will be returned.

Management Update Rule Endpoint

Endpoint: Management Update Rule

Method: POST

RESPONSES:
  • 200: The Redirect Rule with that id was successfully updated
  • 400: Something went wrong during updating of the Redirect Rule. Check the error message for more info

The Update Rule endpoint provides the ability to update the information for a given Redirect Rule in the database. In the post data all of the needed information for the creation of a rule is specified including the Redirect Rule ID which points to which rule you wish to update.

If a Redirect Rule with that ID is not found then a 400 is returned. If the new Redirect Rule fails the rewrite check 400 will be returned as well.

For more information on how the update rule process works take a look at update_redirect_rule() function.

Management Get Rule Endpoint

Endpoint: Management Get Rule

Method: POST

RESPONSES:
  • 200: A Redirect Rule with that ID exists and returned in serialized form
  • 404: A Redirect Rule with that id does NOT exist

The Get Rule endpoint provides the ability to retrieve a Redirect Rule by a given ID specified in the post data of the request. If a Redirect Rule with that id doesn’t exist then a 404 is returned. If a rule with that id exist then it is serialized and returned.

Management Get Page Endpoint

Endpoint: Management Get Page

Method: POST

RESPONSES:
  • 200: A page of redirect rules has been successfully retrieved
  • 404: A page with that page number doesn’t exists or there are no rule to paginate

The Get Page endpoint provides the ability to split up the RedirectRule database into pages with a given size. From this endpoint you can retrieve a given page by number with a given size. The endpoint also accepts filters (optional) which will be applied and the result of the filtered query will be paginated after that. If no items are found with the specified filters then an api_error with error code 404 will be returned.

Management Bulk Import Endpoint

Endpoint: Management Bulk Import Rules

Method: POST

RESPONSES:
  • 200: The import of the CSV file has started successfully
  • 400: Wrong file type or format of the CSV. Look at returned error message

The Bulk Import endpoint provides you with the ability to upload a CSV file in a specific format in order to add a lot of Redirect Rules all at once. The importing may take some time which depends on how large is the CSV file. That is why the endpoint makes use of threads. Before we pass the file to the thread we conduct some basic validation at first which includes:

  1. Is the file of type CSV
  2. Are all the columns specified in the file valid

After this validation has passed successfully then the file is handed over to tbe thread and the import process starts.

Notes:

  1. If duplicate Redirect Rules are encountered in the CSV file they will be ignored/skipped.
  2. If there is a parsing error somewhere in the file then the whole import process fails and all of the so far added Redirect Rules to the DB are rolled back like nothing happened.
  3. At the moment there is no way of telling if an import is finished.

Management Check Request Endpoint

Endpoint: Management Test Request

Method: POST

RESPONSES:
  • 200: All the information gathered from the test run of the request
  • 400: Hyperscan database not loaded. Can’t make search requests

The Test Request endpoint provides the ability to test a request on how it would be process and redirect in a real world scenario. In the post data you specify the request_url which will be ran just as a normal redirect from a worker would. The difference is that not just the final redirect id is returned. A lot of data that might be useful for debugging is exposed as well.

Steps:

  1. The request url is parsed and “host” and “path” are extracted from it
  2. The Hyperscan Manager is called to search but in test mode
  3. After the search is complete we convert all the IDs into their corresponding objects
  4. Everything is serialized and returned

For more information on how the search is done take a look at HsManager().search() function.

Good to test with:
  1. https://iirusa.com/epharmasummitwesta
  2. https://example.com/test/path