Distributed Systems and the End of the API • Hacker News Board

Re: Distributed Systems and the End of the API

#21

Post by kylebrown » Mon, May 12, 2014, 11:08 PM UTC

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 private keys from brute-force cracking attempts.

I'd like to see a comparison of how the blockchain solves the CAP problem, alongside CRDT's. Are they not both solutions to the same problem?

Re: Distributed Systems and the End of the API

#22

Post by pjscott » Mon, May 12, 2014, 11:43 PM UTC

richm44 wrote: post #8

koide wrote: post #4

Earlier quoted context omitted.

two paragraphs later he addresses that point, calling that support limited in current api designs

Not really, he talks about HTTP which wasn't really designed for that purpose. There are plenty of protocols that were. Does this actually have anything to add that isn't covered in http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput... , if so then I'll read further.

It has some very interesting stuff about CRDTs, which is definitely worth a look.

Re: Distributed Systems and the End of the API

#23

Post by mantrax5 » Mon, May 12, 2014, 11:44 PM UTC

jwingy wrote: post #13

CALM and CRDTs are interesting stuff. That being said, I feel like the author is confusing a bit the specific implementations of modern APIs vs the concept of an API which I see as simply some (somewhat standardized) interface to a system which you don't own. Those seem like two different problem domains to me, but perhaps I'm arguing over a different definition of APIs than from what the author is talking about....

I think you got it exactly right. It feels like the author got a little too excited about CRDT-s and forgot all the other principles of good system design (it's about clear stable interface, low coupling, single responsibility and so on).

Re: Distributed Systems and the End of the API

#24

Post by steveklabnik » Mon, May 12, 2014, 11:47 PM UTC

programminggeek wrote: post #16

At least the author is wise enough to see that REST/RPC are not so different from each other. I actually find it interesting that as I was learning about earlier networked "objects" type systems, programmers ran into problems where they were treating the networked objects as if they were local and that the network always works. Now, when we build REST api's they always ship with client libraries that feel like local…

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

Fielding's REST is very much not.

Re: Distributed Systems and the End of the API

#25

Post by derefr » Mon, May 12, 2014, 11:49 PM UTC

mantrax5 wrote: post #18

So he favors exposing a standard set of distributed data models instead of having APIs. What a horrible idea. Exposing implementations is bad because implementations change. Exposing implementations is bad because as you expose the intricacies of your data model to your client (which he claims is a benefit) you in turn obscure and hide the intricacies of your business domain, which will surely not allow you to patch…

> It's in essence like having SQL as your underlying data model, and replacing your API with an open read/write/delete access to your SQL server to the entire world, and hoping everyone will run the right queries and all will be all right.

I find it kind of amusing that this was the original purpose of having an "SQL server": letting people (e.g. auditors) submit arbitrary queries, so you won't have to anticipate what exactly they'll want to do with your data. (Write-access was intended to be segregated to particular database users writing to particular tables, though--basically parallel to using WebDAV with HTTP Basic Auth.)

Re: Distributed Systems and the End of the API

#26

Post by mantrax5 » Mon, May 12, 2014, 11:49 PM UTC

steveklabnik wrote: post #24

programminggeek wrote: post #16

At least the author is wise enough to see that REST/RPC are not so different from each other. I actually find it interesting that as I was learning about earlier networked "objects" type systems, programmers ran into problems where they were treating the networked objects as if they were local and that the network always works. Now, when we build REST api's they always ship with client libraries that feel like local…

"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 everything into the four standard verbs HTTP commonly gives us, no longer adequately describes the business requirements of your app. You can definitely force things to be RESTful, but it's typically not the natural way to build an API. Feels akin to the ORM kind of impedance mismatch in some ways.

Re: Distributed Systems and the End of the API

#27

Post by mantrax5 » Tue, May 13, 2014, 12:06 AM UTC

derefr wrote: post #25

mantrax5 wrote: post #18

So he favors exposing a standard set of distributed data models instead of having APIs. What a horrible idea. Exposing implementations is bad because implementations change. Exposing implementations is bad because as you expose the intricacies of your data model to your client (which he claims is a benefit) you in turn obscure and hide the intricacies of your business domain, which will surely not allow you to patch…

> It's in essence like having SQL as your underlying data model, and replacing your API with an open read/write/delete access to your SQL server to the entire world, and hoping everyone will run the right queries and all will be all right. I find it kind of amusing that this was the original purpose of having an "SQL server": letting people (e.g. auditors) submit arbitrary queries, so you won't have to anticipate wha…

It was, yes, and to this day read-only SQL access to certain tables is not that bad of a practice to allow for report-generating apps within a company.

However the idea of exposing SQL databases publicly as an approach never took hold for many reasons we're today aware of. And the idea of public write access is ridiculous right from its premise.

The anti-API rant of this author shows us that those who don't know their history are doomed to repeat it.

Re: Distributed Systems and the End of the API

#28

Post by icedchai » Tue, May 13, 2014, 12:12 AM UTC

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…

Exactly this. I've seen people doing crazy, non-nonsensical stuff to make their APIs "RESTful". So RESTful that they make no sense.

Re: Distributed Systems and the End of the API

#29

Post by steveklabnik » Tue, May 13, 2014, 12:24 AM UTC

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…

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.

Re: Distributed Systems and the End of the API

#30

Post by logn » Tue, May 13, 2014, 12:29 AM UTC

Rest is less platform dependent than SOAP/RPC. I see that as the main benefit. JSON is easier to work with than XML. The whole idea of service oriented architectures is that users don't need to care about the tech stack details of your service. Rest and JSON do a better job of realizing that vision than SOAP/XML. I don't think anyone's claimed that Rest is a design pattern to end all woes. Maybe we haven't given due thought to what new design patterns (or data structures, architectures, etc) are emerging these days, and in that light, the article presents a lot of interesting pointers.