Hi Zippie,

With regards to the account id, this was in place from the beginning because I knew one day there would be some public account features. And here we are a 2 years later and there are. One day, I'll go through the account stuff and map the same public features that are on the website on the API (when the ID will actually be used) but since there isn't any of that right now, keeping the format standard is what makes sense. Right now, the only way you can access any account features is indeed with a session id. Had I not implemented it this way from day one, implementing a public /account/:id method would be a breaking change for clients.

The paging issue sounds similar to what you already mentioned with the TV search. I'll be looking at that this week.

Ok cool that makes sense thanks for the info

Edit: Would it not make more sense to make the Id segment optional then? I understand the breaking change argument but the method would be doing something distinctly different than it is doing now. Right now why would I force my users to specify an account id when they just want their account info (not linked to an account id but to a session id). I just feel that the way it's set up now is a tad confusing since what you are asking is not what you are getting and even if it changes in the future you would/should not need a session id at all for several of the methods. And for others you will never be able to change info of an other account so why specify the id while all you will ever need is the session id...

Just FYI I love the API, just want to help make is a good as it can be ;)

It's more about two things in particular, than anything else. Invalidating bad requests and keeping things standard across the API as a whole.

For example, lets say you get a created_by_id value from a future list response (doesn't exist right now). With that id, you could make a public request to:

/account/:id/lists

As a public user and get a list of the same lists you see on the website (anything they created or marked as a favourite). I can implement this right now without implementing a breaking change to the API, keep the requests consistent AND support session data as we currently do.

Could I make it optional, sure, I could but when I roll out these public features there will actually be validation of the :id that gets passed in and it was always assumed since the id is required that you're using the ID you got from a user call when creating the user session.

I dunno, truthfully, I never saw providing the ID you got from the /account call when creating a session a very big deal.