Request : What has been updated

Quinlan wrote 7 years ago: 1

That's probably a long shot as it would involved keeping a log of the change but in the api call /updates/shows, it would be nice to have something like a category or a level of what has been changed.

As of now, any change on the show would update the timestamp. But depending on the application, it might not be necessary to update the data in the application if the change was only an addition in the Crew.

On the other side, an episode airdate is an important change and I would be justified to update my side.

For example, if I follow 50 shows and 30 of them had a change as tiny as it can be, I have 30 shows to update. I'm not doing it automatically as I might hammer the API for something trivial.

If the change was about the airdate of an episode, that would justify updating my side. But an addition in the crew is not an urgent change. (At least for me, still an important information ;))

It's only brainstorming of course but the levels could go like this.

Level 1 (Priority)
- airdate (of episode)
- episode (number or else)
- Status
- Etc...

Level 2 (Less important)
- Cast change
- Image change (of episode)
- Etc...

Level 3 (Even less important)
- Crew change
- Trailer added
- Etc...

Depending on the level, I can decide (or the application can) if it is justified to make a call to the API.

Cheers!

gazza911 wrote 7 years ago: 1

Just a few things about this suggestion:

1. It would have to be done as an optional parameter so that it doesn't break any implementations currently using the endpoint - that would mean additional caching required

2. It would double (or even triple) the size of the response

3. People would probably still come back and say stuff like, "well why not just tell us the actual episode id that's been updated" etc

4. What happens when - using your example - both an episode airdate (L1) and a crew member is added (L3) - you wouldn't want to simply show the highest as someone might only be bothered about crew changes.

I understand the intentions behind it, but I don't know how much it would actually solve.

P.S Obviously this is just my own opinion, I've no idea if they'd want to do it or not

Quinlan wrote 7 years ago: 1

1. True.

2. Indeed... Although one endpoint could be that the request has the user api so it shoots only the shows of said user (of their watchlist). Another endpoint could be the levels themselves. /updates/shows/level1

3. Meh! :D

4. I thought about it but I just couldn't imagine a decent solution yet and went for the levels to at least express the idea...

... wich... obviously you got. :) Because right now, if I hit a one-click/update all, I might smash the 20 calls every 10 seconds per IP address barrier. If that happens only for personal usage, someone building a public application is gonna hit that much harder with multiple users.

It's just a thought. :)

gazza911 wrote 7 years ago: 1

Quinlan wrote:
2. Indeed... Although one endpoint could be that the request has the user api so it shoots only the shows of said user (of their watchlist).

If that was done it would most likely be a premium feature.

Quinlan wrote 7 years ago: 1

Obviously.

The level endpoint could be on the public side though as it is related to what the public api is already giving without user input.