Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Distributed Systems and the End of the API

writings.quilt.org

Post reply on HN
Print view View original

31–40 of 102 posts

Re: Distributed Systems and the End of the API

#31

Post by bitwize »

dllthomas wrote: post #19
richm44 wrote: post #2

I stopped at the point where he claimed that APIs were always synchronous, this wasn't even true in the 80s. For example XLib is a rather well used API and is asynchronous (there are many others).

My recollection was that Xlib is an unfortunately synchronous library written for the the wonderfully asynchronous X protocol.

My understanding was that the Xlib protocol's asynchrony was hardly wonderful, and made syncing with vblank and pixel-perfect frames difficult, which motivates its abandonment in favor of the synchronous, local-host-only Wayland protocol.

Re: Distributed Systems and the End of the API

#32

Post by beamatronic »

steveklabnik wrote: post #29
mantrax5 wrote: post #26

Earlier quoted context omitted.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

I agree that many services are simply CRUD wrappers. That doesn't have much to do with the nature of the architecture Fielding proposes. I would be interested in some citations from Fielding which demonstrate that RPC is its organizational principle. I don't think they're there, though.

I'm surprised someone hasn't embraced the idea and built the ultimate generic CRUD wrapper

Re: Distributed Systems and the End of the API

#34

Post by steveklabnik »

beamatronic wrote: post #32
steveklabnik wrote: post #29

Earlier quoted context omitted.

I agree that many services are simply CRUD wrappers. That doesn't have much to do with the nature of the architecture Fielding proposes. I would be interested in some citations from Fielding which demonstrate that RPC is its organizational principle. I don't think they're there, though.

I'm surprised someone hasn't embraced the idea and built the ultimate generic CRUD wrapper

They often fail. See ActiveResource, for example.

Re: Distributed Systems and the End of the API

#35

Post by [deleted] »

steveklabnik wrote: post #29
mantrax5 wrote: post #26

Earlier quoted context omitted.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

I agree that many services are simply CRUD wrappers. That doesn't have much to do with the nature of the architecture Fielding proposes. I would be interested in some citations from Fielding which demonstrate that RPC is its organizational principle. I don't think they're there, though.

[deleted]

Re: Distributed Systems and the End of the API

#36

Post by scotth »

mantrax5 wrote: post #26
steveklabnik wrote: post #24

Earlier quoted context omitted.

"Layman's REST" is very much RPC, yes. Fielding's REST is very much not.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

Aside: Why do you have so many accounts mantrax? At least one of them is dead, and I'm sure you can imagine why.

Re: Distributed Systems and the End of the API

#37

Post by mantrax7 »

scotth wrote: post #36
mantrax5 wrote: post #26

Earlier quoted context omitted.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

Aside: Why do you have so many accounts mantrax? At least one of them is dead, and I'm sure you can imagine why.

None of them are dead. As for why, long story short, because HackerNews is really poorly written. For example I can't even reply from mantrax5 right now.

Re: Distributed Systems and the End of the API

#38

Post by ademarre »

mantrax5 wrote: post #26
steveklabnik wrote: post #24

Earlier quoted context omitted.

"Layman's REST" is very much RPC, yes. Fielding's REST is very much not.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

The problem with REST is that many (I dare say most) who think they are applying it really aren't.

I think this is quite relevant: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

What sets REST apart from RPC is the Hypermedia-as-the-Engine-of-Application-State principle (HATEOAS). With HATEOAS, interaction semantics are removed from URIs and defined in terms of link relations. This decouples clients from URIs; very valuable.

ADD: To equate REST with CRUD overlooks HATEOAS completely. Simple CRUD solutions work on resources that have already been identified, but HATEOAS adds resource identification/addressing and discovery in a very maintainable way.

Re: Distributed Systems and the End of the API

#39

Post by mantrax6 »

scotth wrote: post #36
mantrax5 wrote: post #26

Earlier quoted context omitted.

Fielding's REST is pretty much CRUD in HTTP disguise. Don't get me wrong, this can be great for "hypermedia applications" as Fielding's paper argues. But "hypermedia applications" just doesn't fit what many distributed services do these days. Services are naturally centered arounds verbs (commands and queries) and not nouns (resources), so like with any other CRUD system, at some point a REST API that shoehorns every…

Aside: Why do you have so many accounts mantrax? At least one of them is dead, and I'm sure you can imagine why.

None of them are dead. As for why, long story short, because HackerNews' code is really poorly written. Gateway errors, horrendous response times, bogus limits and false positives. My usage patterns are likely not typical, but this is hardly an excuse for such a poor UX.

For example, I couldn't even respond right now through mantrax5...

Next time I'll just take the alternative and instead of making more accounts, I'll just stop visiting the site completely.

Re: Distributed Systems and the End of the API

#40

Post by marktangotango »

kylebrown wrote: post #21

Distributed API's are a big part of Ethereum. I think the Merkle tree of the bitcoin blockchain (and the Patricia tree of the Ethereum blockchain) might even qualify as a semilattice. In fact, its by the physics of information theory that a cryptographic blockchain solves the consensus problem. Specifically, information theory emerges from the laws of thermodynamics: Maxwell's demon is essentially what secures one's…

FYI information theory entropy and physics entropy really aren't the same thing:

http://physics.ucsd.edu/do-the-math/2013/05/elusive-entropy/

Post reply on HN