On: API design is stuck in the past

[rohan_]

I think this only solves the problem for the API owner, not the consumer, right? You can't use cURL with protobufs like you can with REST to quickly play/interact with the data

[barumi → rohan_]

>>I think this only solves the problem for the API owner, not the consumer, right?

The only problem this solves is their need to sell their product.

This so-called "schema-driven development" approach was already tried in the past and failed miserably. Call it SOAP or OData, the world already gave that a try, saw all the mess and operational and productivity problems it creates, and in spite of the gold mine it represented for tooling vendors and consulting firms, it was a collosal mess.

It's very weird how their selling pitch is based on veiled insults on hoe "the industry is still twenty years behind", but they failed to do their homework to learn the absolute mess that their so-called "schema-driven development" approach left behind.

It's as if they are totally oblivious to why the whole world shifted to "free-form" APIs, which worked far better than the SOAP mess, and their are hell bent on betting on a rehash of the bad old days.

[kentonv → barumi]

Basically everything inside Google has been built this way through their whole history. Are you calling them a failure?

[barumi → kentonv]

Just because a company managed to do stuff a certain way that does not mean that way is the right way or adequate or good.

Enough with this cargo cult bullshit approach to technical problems.

[kentonv → barumi]

Your argument seems to be entirely ad hominem.

SOAP failed because it was a bad design (overcomplicated, verbose, XML-based), not because it used schemas. I've never heard anyone who uses Protobuf say it reminds them of SOAP.

[musingsole → kentonv]

Your previous post is an appeal to authority. You're both mired in fallacies.

[cfors → rohan_]

There is tooling built to easily do grpc requests from the command line[0] or even a GUI if that's your thing[1].

The tooling isn't quite as ubiquitous as cURL, but if anything I would think that its even easier because you have introspection into the contract with a .proto file.

[0] https://github.com/fullstorydev/grpcurl [1] https://github.com/uw-labs/bloomrpc

[kentonv → cfors]

Exactly. JSON is benefitting from the fact that it can ride on top of existing non-dedicated tooling in an ad hoc way. Protobuf/gRPC needs dedicated tooling designed to replace what JSON can do with cURL. But that tooling has the potential to be much better than what can be accomplished with JSON, because it can actually type-check your input (e.g. catching typo'd field names) and maybe even let you explore the schema interactively. E.g. imagine having bash tab completion for these APIs -- easy if you have the schema.