Add Harvest Records Endpoint to API

[karenmajewicz]

Feature request

Create a new API endpoint for Harvest records.

Background

Currently, harvest-related fields (e.g., Endpoint URL, Accrual Method, Harvest Workflow) are stored directly on Resource records (especially Websites). We are transitioning toward a model where:

• Resource records describe just the resource itself
• Harvest records describe how the resource(s) were obtained and maintained

Rationale

• Avoid overloading Resource records with BTAA-specific workflow and operational fields
• Keep Resource metadata aligned with community standards
• Support future multi-user and multi-source workflows (e.g., external sources like OpenGeoMetadata)
• Enable harvesting scripts to query APIs instead of CSV exports
• Reduce duplication by storing harvest details once instead of across thousands of records
• Power (in part) administrative and analytics dashboads

Transition phase

• Temporary Harvest records are being created in GBL Admin using Resource Class = Series

  • “Series” is being used only as a placeholder and does not reflect the intended meaning of these records

• Existing Resource records will continue to store harvest-related fields during this phase

  • This ensures backward compatibility with current workflows and UI behavior

• A new Harvest API endpoint can treat these placeholder records as a distinct type

  • This allows us to begin working with Harvest records as a separate entity
  • It also enables a gradual transition before dedicated metadata/admin tooling is developed

Suggested endpoint name

GET /api/v1/harvests
GET /api/v1/harvests/{id}

Fields to include

Each Harvest record should expose the following fields:

• id
• dct_title_s
• dct_description_sm
• b1g_code_s
• dct_identifier_sm
• b1g_dcat_endpointURL_s
• b1g_dcat_endpointDescription_s
• b1g_websitePlatform_s
• b1g_harvestWorkflow_s
• b1g_dct_accrualMethod_s
• b1g_dct_accrualPeriodicity_s
• b1g_lastHarvested_dt
• b1g_adminNote_sm
• b1g_adminTags_sm
• b1g_dct_provenance_sm