• fubo@lemmy.world
    link
    fedilink
    arrow-up
    11
    arrow-down
    1
    ·
    1 year ago

    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.

    • ono@lemmy.ca
      link
      fedilink
      English
      arrow-up
      20
      arrow-down
      1
      ·
      edit-2
      1 year ago

      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.

      • fubo@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 year ago

        Sure, sure, but is finger 8-bit-safe?

        'Cause if you have to uuencode it, that’s a whole mess.

        • ono@lemmy.ca
          link
          fedilink
          English
          arrow-up
          5
          arrow-down
          1
          ·
          edit-2
          1 year ago

          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.)