Implement a max spot age filter. Closes #18

This commit is contained in:
Ian Renton
2025-10-02 09:57:25 +01:00
parent 9640c0e0c1
commit 1a9dc0b634
8 changed files with 49 additions and 17 deletions

View File

@@ -4,7 +4,7 @@ info:
description: |-
(S)pothole is a utility to aggregate "spots" from amateur radio DX clusters and xOTA spotting sites, and provide an open JSON API as well as a website to browse the data.
While there are other web-based interfaces to DX clusters, and sites that aggregate spots from various outfoor activity programmes for amateur radio, (S)pothole differentiates itself by supporting a large number of data sources, and by being "API first" rather than just providing a web front-end. This allows other software to be built on top of it. Spothole itself is also open source, Public Domain licenced code that anyone can take and modify.
While there are other web-based interfaces to DX clusters, and sites that aggregate spots from various outfoor activity programmes for amateur radio, (S)pothole differentiates itself by supporting a large number of data sources, and by being "API first" rather than just providing a web front-end. This allows other software to be built on top of it. (S)pothole itself is also open source, Public Domain licenced code that anyone can take and modify.
contact:
email: ian@ianrenton.com
license:
@@ -30,13 +30,19 @@ paths:
type: integer
- name: since
in: query
description: Limit the spots to only ones at this time or later. Time in UTC seconds since UNIX epoch.
description: Limit the spots to only ones at this time or later. Time in UTC seconds since UNIX epoch. Equivalent to "max_age" but saves the client having to work out how many seconds ago "midnight" was.
required: false
schema:
type: integer
- name: max_age
in: query
description: Limit the spots to only ones received in the last 'n' seconds. Equivalent to "since" but saves the client having to work out what time was 'n' seconds ago on every call. Refer to the "max_spot_age" in the /options call to figure out what the maximum useful value you can provide is. Larger values will still be accepted, there just won't be any spots in the system older than max_spot_age.
required: false
schema:
type: integer
- name: received_since
in: query
description: Limit the spots to only ones that the system found out about at this time or later. Time in UTC seconds since UNIX epoch. If you are using a front-end that tracks the last time it queried the API and requests spots since then, you want *this* version of the query parameter, not "since", because otherwise it may miss things.
description: Limit the spots to only ones that the system found out about at this time or later. Time in UTC seconds since UNIX epoch. If you are using a front-end that tracks the last time it queried the API and requests spots since then, you want *this* version of the query parameter, not "since", because otherwise it may miss things. The logic is "greater than" rather than "greater than or equal to", so you can submit the time of the last received item back to this call and you will get all the more recent spots back, without duplicating the previous latest spot.
required: false
schema:
type: integer
@@ -188,6 +194,14 @@ paths:
schema:
type: object
properties:
"software-version":
type: string
description: The version number of the software.
example: "1.0.1"
"server-owner-callsign":
type: string
description: The callsign of this server's operator.
example: "M0TRT"
"uptime":
type: string
description: The amount of time the software has been running for.
@@ -283,6 +297,10 @@ paths:
items:
type: string
example: "EU"
max_spot_age:
type: integer
description: The maximum age, in seconds, of any spot before it will be deleted by the system. When querying the /api/spots endpoint and providing a "max_age" or "since" parameter, there is no point providing a number larger than this, because the system drops all spots older than this.
example: 3600
components:
schemas: