The convention since the early days of HTTP has been that each document or object should have its own distinct path. Query parameters are intended to modify or filter requests to a resource, not to define the resource itself. They allow for variations in representation — for example, filtering search results or paginating lists — but the core identity of a document should reside in the path.

When query parameters are used as primary identifiers, a number of problems arise. Caching systems and content delivery networks often treat such URLs differently, reducing cache efficiency. Search engines may fail to recognize canonical versions of a document, which can fragment indexing and degrade discoverability. Social networks and link unfurlers also tend to handle query URLs inconsistently, which can affect how shared documents appear.

In web architecture and RESTful design, clarity of resource identity is central. Paths define what the resource is; query parameters describe how we want to interact with it. Using query parameters to identify documents breaks this separation and undermines long-established conventions that make the web predictable and interoperable.

Profiles and Contact are resources. Feeds are documents; therefore, they require their own URL, both human- and machine-readable.

Examples of my feed on Seed Team Talks:

Then we can use Query Parameters for filtering and different App Views!