undefined | Better HN

0 pointsrichardwhiuk9y ago0 comments

I'm definitely not trolling - it's just that's not how clients work.

I don't write a client by doing a random walk through the API until I get to the information I need, I want to call the API that I know I need to give me the information that I want, and for performance, I want it all to be returned on a single call ideally.

e.g. If I want user B's playlist, I don't want to have to crawl:

/friends/ => ['b': { 'links': {'info': '/friends/619'} }]

/friends/619 => {'links': {'playlist': '/friends/619/playlist' } }

/friends/619/playlist

0 comments

3 comments · 1 top-level

w4tson9y ago· 2 in thread

But it's not a random walk. And it sure beats custom apis returning random bags of data for any given UI screen.

Sometimes you do a few more web calls than you might otherwise. If you can get away with it then great! Because the benefits are plenty

Hell! Even just having the uri of where the resource came from is useful enough. That's before you've introduced related resources.

tdriggs9y ago

At this point aren't you still hard coding commands, but using "links" rather than URLs? And doesn't the dependency on every link in the chain outweigh one - easily maintained - URL?

macca3219y ago

You're hard-coding 'terms' from a hypermedia 'vocab'.

The thing is, if you use well-known terms, your client will work against ANY API that uses those terms, not just the one that you coded it to work against.

Not only that, but the APIs will have flexibility to move things around, or delegate functionality to other hosts by linking through.

As for the cost of walking the chain, once a target resource has been found the can be cached, and you only need to rewalk if the resource 404/410s.

j / k navigate · click thread line to collapse