Request For Comments (RFCs)
  • Request for comments (RFC)
  • RFC 001: Matcher architecture
  • RFC 002: Archival Storage Service
  • RFC 003: Asset Access
  • RFC 004: METS Adapter
  • RFC 005: Reporting Pipeline
  • RFC 006: Reindexer architecture
  • RFC 007: Goobi Upload
  • RFC 008: API Filtering
  • RFC 009: AWS account setup
  • RFC 010: Data model
  • RFC 011: Network Architecture
  • RFC 012: API Architecture
  • RFC 013: Release & Deployment tracking
    • Deployment example
    • Version 1
  • RFC 014: Born digital workflow
  • RFC 015: How we work
    • Code Reviews
    • Shared Libraries
  • RFC 016: Holdings service
  • URL Design
  • Pipeline Tracing
  • Platform Reliability
    • CI/CD
    • Observability
    • Reliability
  • RFC 020: Locations and requesting
  • RFC 021: Data science in the pipeline
  • RFC 022: Logging
    • Logging example
  • RFC 023: Images endpoint
  • RFC 024: Library management
  • RFC 025: Tagging our Terraform resources
  • RFC 026: Relevance reporting service
  • RFC 026: Relation Embedder
  • RFC 027: Pipeline Intermediate Storage
  • RFC 029: Work state modelling
  • Pipeline merging
  • RFC 031: Relation Batcher
  • RFC 032: Calm deletion watcher
  • RFC 033: Api internal model versioning
  • RFC 034: Modelling Locations in the Catalogue API
  • RFC 035: Modelling MARC 856 "web linking entry"
  • RFC 036: Modelling holdings records
  • API faceting principles & expectations
  • Matcher versioning
  • Requesting API design
  • TEI Adapter
  • Tracking changes to the Miro data
  • How do we tell users how to find stuff?
  • Removing deleted records from (re)indexes
  • RFC 044: Tracking Patron Deletions
  • Work relationships in Sierra, part 2
    • Work relationships in Sierra
  • Born Digital in IIIF
  • Transitive hierarchies in Sierra
  • RFC 047: Changing the structure of the Catalogue API index
  • RFC 048: Concepts work plan
  • RFC 049: Changing how aggregations are retrieved by the Catalogue API
  • RFC 050: Design considerations for the concepts API
  • RFC 051: Ingesting Library of Congress concepts
  • RFC: 052: The Concepts Pipeline - phase one
  • RFC 053: Logging in Lambdas
  • RFC 054: Authoritative ids with multiple Canonical ids.
  • RFC 055: Genres as Concepts
  • RFC 055: Content API
    • Content API: articles endpoint
    • Content API: Events endpoint
    • Content API: exhibitions endpoint
    • The future of this endpoint
  • RFC 056: Prismic to Elasticsearch ETL pipeline
  • RFC 57: Relevance testing
    • Examples of rank CLI usage
  • RFC 059: Splitting the catalogue pipeline Terraform
  • RFC 060: Service health-check principles
  • RFC 060: Offsite requesting
    • Sierra locations in the Catalogue API
  • Content-api: next steps
Powered by GitBook
On this page
  • Problem statement
  • Suggested solution
  • Structured filtering
  • Full text querying
  • Sorting

RFC 008: API Filtering

Last updated: 19 October 2018.

Problem statement

To ensure a consistent developer experience across our APIs, we need to agree a set of patterns for filtering and sorting. This document outlines our approach.

Suggested solution

There are three complementary parts to this:

  • structured filtering

  • full text querying

  • sorting

Structured filtering

Structured filters are non-scoring (ie, they do not result in relevance scores) queries that can be used to restrict the resources returned, without influencing the order in which they are returned.

Structured filters have the following characteristics:

  • They are supplied as query parameters

  • They have the name of the property they are used filter

  • Multiple query parameters are combined using AND

  • Multiple comma (,) separated values within a single query parameter are combined using OR

  • Closed-open ranges are supported using /

  • Dotted syntax is used to specify paths

  • id is implicit in parameter paths

Examples:

Filter for a single work type:

/works?workType=book

Filter for multiple work types:

/works?workType=book,ebook

Filter for multiple work types with a single subject:

/works?workType=book,ebook&subjects.concepts={id}

Filter for multiple work types with a multiple co-occurring subjects:

/works?workType=book,ebook&subjects.concepts={subjectID1}&subjects.concepts={subjectID2}

Searching within structured data within structured filtering

Full text querying

Full text querying is supported as a scoring query that can be used to restrict the resources returned, by default returning them in relevance order.

Full text querying has the following characteristics:

  • It is supplied as a single query parameter

  • The query parameter is called query

  • It can be combined with any combination of structured filters

  • Some field based and other advanced full text querying may be supported, but is service dependent

Examples:

Find all works that mention skeletons:

/works?query=skeletons

Find all works that mention skeletons and are books or ebooks:

/works?query=skeletons&workType=book,ebook

Sorting

The default ordering for a collection of resources is service dependent. It can also vary for different kinds of resource within the same service, to ensure that the default ordering is the most appropriate in the majority of cases.

In addition to this:

  • Use of full text querying should change the default order to ordering by relevance

  • This can be overridden using a sort parameter

  • The value of this parameter is a comma separated list of properties

  • The order within a property can be changed using asc and desc modifiers

Example:

/works?query=skeletons&sort=year desc,title
PreviousRFC 007: Goobi UploadNextRFC 009: AWS account setup

Last updated 10 months ago