4 ms·

I get this on one level but wow can you tell the difference between when a team uses the API they offer users and when they don’t, and the “single API” approach

by rtpg 3y ago

I get this on one level but wow can you tell the difference between when a team uses the API they offer users and when they don’t, and the “single API” approach gets you there so well. I have basically never seen a nice user-facing API when it’s been split out. Sometimes that’s fine, but at least for enterprise use cases having a “real” API just feels like table stakes in so many domains for getting bigger clients onboard.

8n4vidtmkvmk 3y ago
I thought I knew what the author meant until I got to the end. I could be that they're referring to HTML as one API, and JSON-RPC as the other API. Originally I thought they meant 2 JSON APIs. One that's tightly coupled with the HTML to handle all the "ajax" requests, and the other for 3rd parties to fetch arbitrary bits of data. Otherwise, I know what you mean. My company has our internal RPCs and then our customer-facing API and the customer one hasn't been updated in ages and it's just a thin layer over some old internal RPCs we used to have and now we have to maintain backwards compatibility but keep breaking it anyway.
- rtpg 3y ago
  Yeah here they’re talking about a JSON API and then just “serving HTML” (which is its own API). I really think it’s so valuable to take what you use internally seriously, exposing and documenting it to end users is a great way to avoid hackiness, and just leads to more regular designs IMO. More work of course but … not that much in the vast majority of cases
  - BlueTemplar 3y ago
    Another issue might be security ? Completely different assumptions about it between internal and external sounds like you would want avoid sharing them anyway ?
    - erhaetherth 3y ago
      1st party APIs that are exposed to the client need to be secure anyway or users will discover and start using it. I found a library on GitHub that does exactly this to our app. They reverse-engineered nearly everything. I'm sure we could break the lib if we encrypt a few tokens but no one seems to care. I don't mind either, since we clearly aren't giving users a proper API.

by rtpg 3y ago

8n4vidtmkvmk 3y ago

I thought I knew what the author meant until I got to the end. I could be that they're referring to HTML as one API, and JSON-RPC as the other API. Originally I thought they meant 2 JSON APIs. One that's tightly coupled with the HTML to handle all the "ajax" requests, and the other for 3rd parties to fetch arbitrary bits of data. Otherwise, I know what you mean. My company has our internal RPCs and then our customer-facing API and the customer one hasn't been updated in ages and it's just a thin layer over some old internal RPCs we used to have and now we have to maintain backwards compatibility but keep breaking it anyway.

rtpg 3y ago
Yeah here they’re talking about a JSON API and then just “serving HTML” (which is its own API). I really think it’s so valuable to take what you use internally seriously, exposing and documenting it to end users is a great way to avoid hackiness, and just leads to more regular designs IMO. More work of course but … not that much in the vast majority of cases
- BlueTemplar 3y ago
  Another issue might be security ? Completely different assumptions about it between internal and external sounds like you would want avoid sharing them anyway ?
  - erhaetherth 3y ago
    1st party APIs that are exposed to the client need to be secure anyway or users will discover and start using it. I found a library on GitHub that does exactly this to our app. They reverse-engineered nearly everything. I'm sure we could break the lib if we encrypt a few tokens but no one seems to care. I don't mind either, since we clearly aren't giving users a proper API.