Consider supporting a new optional guid parameter to the Episodes > By Feed ID/URL endpoints

[johnspurlock]

Using item guid as the unique id for a podcast episode (rss item) within a feed is common, especially when crossing the boundary between various podcasting services from different companies with their own internal id schemes.

It is sometimes even essential if referring to an episode before it is available in the PI database, for example when referencing an episode within the feed item itself, for example when embedding a link to a 3rd party comment service within the item itself.

It would be great if there was a way to resolve (feed, item guid) into the associated PI episode, perhaps leveraging a nonunique composite index (podcastid + item guid) in the PI database itself.

One simple way to expose this using the existing endpoints would be to support a new optional guid query param to the existing Get episodes by Feed ID and Get episodes by Feed URL API endpoints.

This way, other systems could do quick resolution regardless of which feed identifier they have, and no new endpoints would need to be created that would effectively do the same thing.

[jamescridland]

I support the use of GUIDs (both episode and podcast level) wherever we can.

[daveajones]

The episodes table in the DB already has a composite index on feedid+guid so this should be doable. Issue for this is here:

Podcastindex-org/docs-api#76

[dellagustin]

Hi @daveajones , @johnspurlock , I'm always in favor of giving more importance to an episode's guid (even though I believe there are still feeds out there without it).

Anyhow, I was confused when reading this issue at first, because it is in the namespace repo, so I was reading it looking for a namespace related proposal.
I'd like to suggest moving the issue to either the https://github.com/Podcastindex-org/docs-api or https://github.com/Podcastindex-org/api.
By the way, which of this two is the official place to discuss proposals regarding the API?

Best Regards,
Gui.

[daveajones]

Closing this issue since it moved to the api-docs repo.