@rixx @MaZderMind regarding #314

I'd like to merge this, as it builds upon the previous approach to IDs in the public API. However changing the URLs will probably break the parsing done by @rixx?

Well, I know about it now, but it may also break other projects who make the same assumptions. Otoh they'll notice and fix it. ;)

Wouldn't it be better to replace the event_id in the related event section with the event_guid? Because you can use the guid to look up the event in the API, but you can't do that with the slug (or can you?)

Ah, also, since you want to remove the IDs from your API entirely: The API provides the related events twice, once in the format you're fixing in this PR, and once in the metadata field:

  "metadata": {
    "related": {
      "5355": 11,
      "5358": 12,
      "5359": 13,
      "5370": 16,
      "5382": 19,
      "5390": 6,
      "5393": 11,
      "5394": 11,
      "5398": 11,
      "5401": 20
    }
  },
  "related": [
    {
      "event_id": "5355",
      "weight": 11
    },
    {
      "event_id": "5358",
      "weight": 12
    },
    {
      "event_id": "5359",
      "weight": 13
    },
    {
      "event_id": "5370",
      "weight": 16
    },
    {
      "event_id": "5382",
      "weight": 19
    },
    {
      "event_id": "5390",
      "weight": 6
    },
    {
      "event_id": "5393",
      "weight": 11
    },
    {
      "event_id": "5394",
      "weight": 11
    },
    {
      "event_id": "5398",
      "weight": 11
    },
    {
      "event_id": "5401",
      "weight": 20
    }
  ],

So you're still exposing IDs in that second place, as keys.

Hey guys,

I may be late to the party, but I haven't had any time the last couple of weeks. The changes here currently break the c3media library from @johnjohndoe and therefore also my TV App see issue.

Until now I was also relying on the id at the end of every url. I will try to adapt to the new API, but is there any way to find out about those changes beforehand or are there any plans on versioning the API?
Breaking changes like this make it hard to maintain client applications :(

He @stefanmedack

I don't plan on versioning the API.. that would mean we have to keep support for the old API and we barely have enough time for one...

If I'd know who is using the API I could ping them in the future. Let's create a wiki page?

@manno Are you aware of the list of projects? I would guess all the people behind would be interested to be informed up front about major changes.

@johnjohndoe that list has quite a few github projects. However we only add non commercial front end projects.
The wiki could list all kinds of projects. Not sure how to use that without having actual contact addresses for the listed projects. I'd want to avoid a mailing list.

My thought was that each of such projects might already have or could add a project email address to their project site or repository README or somewhere in the source code. Then in the wiki each project could be listed with its name and a link to the location of the up-to-date email address. With this approach it is less likely that the email address becomes outdated.