Nit on documentation for /users/show
Kee Hinckley
fact I assume that it's that one or the other is required?
Since I'm nitting. The whole "id" thing (changing the URL rather than
being an argument, and being either a number OR a name) makes
implementing the API more complicated that it really needs to be. And
it can't make things any simpler on your end.
Julio Biason
> Since I'm nitting. The whole "id" thing (changing the URL rather than being
> an argument, and being either a number OR a name) makes implementing the API
> more complicated that it really needs to be. And it can't make things any
> simpler on your end.
I don't see any thing being more complicated. You'd have to change a
variable in the post, anyway. Also, that's what the RESTful idea is
about.
--
Julio Biason <julio....@gmail.com>
Twitter: http://twitter.com/juliobiason
Kee Hinckley
> On Mon, May 26, 2008 at 10:44 AM, Kee Hinckley
> <naz...@somewhere.com> wrote:
>> Since I'm nitting. The whole "id" thing (changing the URL rather
>> than being
>> an argument, and being either a number OR a name) makes
>> implementing the API
>> more complicated that it really needs to be. And it can't make
>> things any
>> simpler on your end.
>
> I don't see any thing being more complicated. You'd have to change a
> variable in the post, anyway. Also, that's what the RESTful idea is
> about.
I'm not sure where REST comes into the picture. I have no problem with
id, just with it being special.
I'm just looking at the API and I can describe the entire thing in a
static table like this.
user_timeline => {
_url => '/statuses/user_timeline',
_type => 'GET',
_auth => OPTIONAL,
id => OPTIONAL,
count => OPTIONAL,
since => OPTIONAL,
},
and easily have a single handler generate the URLs, make sure the
caller is providing all the necessary arguments, and handle the
responses... except that I have to special case 'id', because changes
the url, not the arguments.
As it happens, it's only ever 'id', and it's consistent, so I can just
special case 'id' as
if (id) append '/idval' to the url
else add argument to the url
But why complicate things?
As for the use of id as either a name or an internal database id,
that's clearly adding code on the server side, since the same value
has two very different lookup mechanisms. It's not a performance
issue, it just is something that could have been neater.
As I said, it's a nit.
Julio Biason
> I'm not sure where REST comes into the picture. I have no problem with id,
> just with it being special.
Oh, sorry. Brain wired incorrectly these days.
But yes, seems... weird. Maybe it should have something like:
user/<user_id>/friends_timeline
And, if <user_id> != <authenticated_user_id>, return a 401 status.
Also, I think the same thing can be archived (without the "id"
parameter) using
/statuses/friends_timeline/<id>.json