Continued from this post.
My first thought is that it seems like I should be able to generate an RSS feed pretty easily. Maybe I should be looking to what gets RSS feeds contain as guidance for what I return from the feed endpoint.
My second thought is that a completely different approach would be to – instead of returning an array with a bunch of feed item dictionaries created on the server – return a JSON dictionary containing arrays for each item type (songs, shows, videos) and have the logic to display and sort them in the client. That would certainly make the server code simpler. The client could have a sync object that posts a notification when it starts and stops, and then I’d just do a Core Data fetch of all the different types and mash them together into an NSArray in the feed controller.
I’ll still keep it as one API endpoint (instead of calling shows, then songs, etc) since Azure charges me something per API call, it’s the same number of database calls, and it’s easier for dealing with when sync starts and ends on the client.
The reason this appeals to me is that I fear each of the different item types will end up being different enough that I won’t really save that much code on the client by trying to normalize feed items on the server. It feels like it could become kind of restrictive later. It should also make caching easier since it means I can have a one to one match between my server and client data model instead of needing the sort of imaginary “feed item” objects. The last benefit I can think of is that it saves me from having to make another API call every time I want to show a detail item.
The downside is that the RSS feed now would be extra code if I wanted to do that. Not much extra code though, and I was only really thinking of doing it because it seemed like kind of a freebie.
I think I’ll do this unless someone gives me a good reason why I shouldn’t.
