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.
Programming
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
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.)