One curious element of this: The least important part of a data API is the network protocol you use to get the data. The same “API” would be just as good over olde-schoole FTP instead of HTTPS.
The same “API” would be just as good over olde-schoole FTP instead of HTTPS.
I can’t agree with this, because FTP uses separate connections for requests and data, making it significantly more complicated than a single-connection protocol. (Note especially that the conventional default is for the remote host to initiate the second channel, so the requestor must also listen for and accept incoming connections!) If you want to stay old-school, the Finger protocol would be a better example of the point you’re trying to make.
Practically speaking, though, HTTPS was an excellent choice here. It provides an appropriate level of data authenticity without needlessly complicating things, and easy-to-use implementations are ubiquitous.
Sure, sure, but is finger 8-bit-safe?
'Cause if you have to uuencode it, that’s a whole mess.
Sure, sure, but is finger 8-bit-safe?
Originally, I believe it was. (Edit: Confirmed by RFC 742.)
FTP, on the other hand, used 7-bit ASCII mode by default; Using 8-bit mode would normally require multiple request-response round trips. (There were eventually servers that defaulted to 8-bit, but they were atypical and arrived later.)