Suporte do The Movie Database
Suporte → Suporte da API
Account lists API inconsistency
publicado por ZippieSTAFFMOD em 10 novembro 2013 às 9:01 AM
My concern is with the following API call /3/account/{id}/lists. The documentation specifies that one needs to provide and Id, I assumed the account id. Now what ever you enter it will provided you with the list of lists associated with the provided session id. On the other hand lists linked to accounts are freely accessible on the site.
So for me either the id requirement should be removed or the session requirement should be dropped (or a new API signature should added to support both scenarios). Now you need to provide a (bogus) account id and a user session id for this to work at all.
In addition the paging system seems to work slightly different than for example the search results. When entering a wrong page (ex 2 where the total pages is 1) the returned page will be the exact same result as when requesting page 1. The search calls would return a page 2 but with no results since that page does not contain any. While this is fine it would expect the different API calls to use the same type of system so that it's a bit more transparent to use.
PS: Seems that this account id is required for all account methods while I don't quite see the point due to the points raised above.
Regards, Thomas
Resposta de Travis Bell
em 11 novembro 2013 às 10:25 AM
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/:idmethod 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.
Resposta de Zippie
em 11 novembro 2013 às 2:00 PM
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 ;)
Resposta de Travis Bell
em 11 novembro 2013 às 9:44 PM
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_idvalue from a future list response (doesn't exist right now). With that id, you could make a public request to: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.