RSS identity reference

RSS identity API

An identity API should return stable records and explain every match, redirect, alias, and validation result without hiding uncertainty.

Core resources

Model feeds, aliases, observations, events, validations, ownership claims, and items separately. Give the logical feed an opaque immutable ID. Keep canonical URLs and historic aliases as time-aware relationships.

Suggested endpoints

GET /v1/feeds/{feed_id}
GET /v1/resolve?url={feed_url}
GET /v1/feeds/{feed_id}/aliases
GET /v1/feeds/{feed_id}/events
GET /v1/feeds/{feed_id}/validation/latest
POST /v1/resolutions

Read endpoints should support ETags, pagination, and stable error semantics. A network resolution may be asynchronous and return an operation resource.

Resolver safety

Reject unsupported schemes, block private network targets, cap redirects and response size, enforce timeouts, sanitize logs, and parse with hardened libraries. A resolver is an outbound network service and must be designed against server-side request forgery.

Evidence-rich responses

Return requested URL, redirect chain, final URL, format, validation summary, match level, signals, observation time, and provenance. Distinguish publisher assertions from fetched observations and registry inferences.

Contract and lifecycle

Publish a machine-readable contract, version the semantics, retain tombstones for merged or retired IDs, and document rate limits and data freshness. The article Designing an RSS Feed Identity API and Registry expands this architecture.