The most inefficient API you could design!

But backwards compatible!

Seriously. Instead of a single, clean restaurant reservation HTTP POST API, the future is two neural nets modulating and demodulating the request to and from inexact and potentially ambiguous English audio.

Silly. The future is a stenographic handshake in the initial greeting, which negotiates an upgrade to a proprietary gRPC8 protocol when the caller and recipient are both Google, which Google uses to get a monopoly on telephone-mediated social interactions which it can then monetize by building a social graph to more efficiently target advertising to captive audiences riding Waymo cars.

You are joking, but it's not funny in the future. :S

To be fair, we could make the same complaint in regards to the web - it's largely all plain-text on a line, as opposed to some form of compiled bytecode (I know, it's coming).

What we lose in using human speech for precision we make up in it being pretty much universal. Talk about an adaptable interface. You can phone the restaurant and do anything from reserving a table to ordering takeout to informing them that their cat is on fire.

Not backwards compatible. :)

(I mean that as both a joke and a real comment - you could never force every restaurent in the world to learn REST, but you sure can call a bunch of them)

I think Neal Stephenson would make the case that we started down that inefficiency road when we replaced telegraph signal with voice in the first place. ;)

https://www.wired.com/1996/12/ffglass/

Or Alexa answers the phone and refuses to speak to it.

I wonder if it would be able to tell if it was talking to another Duplex bot and instead of speaking in English, it would communicate more efficiently.

I wonder if they detect that and solve whatever task it is directly then.

It'd be trivial to detect if they transmit high-frequency noise over the line, and then fallback to DTMF tones.

That'd be a creepy conversation to listen in on. "Ah yes, I see you are a robot too." Proceeds to transmit data through dial-up-esque noise

Since the restaurant in this situation is clearly using a digital booking system already why would Google (or whatever service inherits this kind of bot call) not just check on the popular booking sites before placing the call?