Bug 1041926 - [RFE][keystone]: Dynamic filter discovery on REST API
Summary: [RFE][keystone]: Dynamic filter discovery on REST API
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/keys...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 20:06 UTC by RHOS Integration
Modified: 2015-07-22 17:59 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:32:29 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 20:06:36 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/dynamic-filter-discovery-on-rest-api.

Description:

Problem
=====

Keystone V3 specification supports filter on list APIs and the supported filters are defined in specification docs. This approach of static filter discovery is not sufficient to support following use cases

1. Clients (e.g. Horizon) wants to dynamically discover filters and render them in their system. This way they don't have to change their implementation (code) each time when a new filter is added or removed from the API.
 
2. There is no way for a clients (e.g. Horizon) to validate Input value for filter by end users.

3. This approach is not  convenient for extension providers who want to have additional filters on extended APIs.

Proposal
=====

Keystone list APIs has to support additional path parameter called "filters", request with this parameter should return JSON response with list of supported filters in certain format.  This way clients can conveniently discover all the supported filters on an API, render them in their system (or web page) and they can validate the user input values for filter based on the response.

Following is data structure for the filters response.

{
  "filters": [
    {
      "name": "--filter-name--",
      "type": "pick-list",
      "isExclusive": "true",
      "possibleValues": ["value1","value2"],
      "description": "--filter description--"
    },
    {
      "name": "--filter-name--",
      "type": "integer",
      "isExclusive": "false",
      "description": "--filter description--"
    },
    {
      "name": "--filter-name--",
      "type": "String",
      "isExclusive": "false",
      "description": "--filter description--"
    },
    {
      "name": "--filter-name--",
      "type": "boolean",
      "isExclusive": "false",
      "description": "--filter description--"
    }
  ]
}

Examples
======

API : GET /endpoints/filters

Response
{
  "filters": [
    {
      "name": "interface",
      "type": "pick-list",
      "isExclusive": "false",
      "possibleValues": ["public","internal","restricted"],
      "description": "optional filter"
    },
    {
      "name": "service_id",
      "type": "integer",
      "isExclusive": "false",
      "description": "optional filter"
    },
    {
      "name": "region",
      "type": "pick-list",
      "isExclusive": "false",
      "possibleValues": ["region-a-geo1","region-a-geo2","region-a-geo2"],
      "description": "optional filter"
    }
  ]
}

API: GET /users/filters

Response
{
  "filters": [
    {
      "name": "enabled",
      "type": "boolean",
      "isExclusive": "false",
      "description": "optional filter"
    },
    {
      "name": "domain_name",
      "type": "String",
      "isExclusive": "false",
      "description": "optional filter"
    }
  ]
}

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.