When two apps share data, make the contract visible

The connection exists in code

Nottinghamshire Jobs publishes vacancy data, and My Next Step’s current application code has a catalogue route that reads that feed. This describes implemented source, not a claim that a particular public installation is using the latest version.

Once a producer and a consumer share data, changing one side can expose assumptions on the other. A field that becomes optional, a new header or a changed URL shape needs a deliberate compatibility decision.

Tolerant values, explicit structure

The My Next Step parser supports specific CSV schemas and checks column structure. It can omit a missing optional date and skip a row with an unusable application URL. It does not interpret arbitrary headers as though they meant the expected fields.

Some row-local problems can be isolated. A structural mismatch can make every column ambiguous and should produce an explicit failure. Never fill in an invented deadline or silently present an empty catalogue as a successful import. Keep counts and reasons useful for diagnosis.

Unsupported header/schema -> reject with a diagnostic
Known optional value missing -> omit or normalise
Unusable application URL -> skip that row, record why
No usable rows -> report an unavailable catalogue

Test both sides of a change

Keep contract examples for supported versions, missing optional values, invalid URLs and a wholly unusable feed. Test the producer’s new output against the consumer before adopting it. Preserve source and freshness information so the person knows what they are reading.

Compatibility does not mean accepting everything. It means agreeing which changes are safe to understand, and making the other changes visible before someone relies on the result.

Related project