3 ms·
all very true, the one exception being API design. once it's published and used, it can quickly become a nightmare of legacy code that haunts you well beyond it
by leeoniya 14y ago
all very true, the one exception being API design. once it's published and used, it can quickly become a nightmare of legacy code that haunts you well beyond its expiration date...even if versioned. often this does, in fact, translate to needing proper rest routes from the get-go, etc. (which can just be mod-rewritten of course), but releasing a prototype API can be quite scary especially if your service turns out to be extremely popular and is plagued by its own too-early success.
api iteration is something most of my projects go through as i use my own systems and refactor the internals to reduce the almost inevitable initial complexity as it begins to piss me off.
to a degree, i suppose the adage still holds true, but moreso as "bad api design on product A leads to better api design on product B (or v2)"
- jamesaguilar 14y agoThis is why using your API two or three ways before publishing it is so important. There's a quote that goes something like, "If you build a plugin system with one plugin, that's all it'll ever support. But if you build it with three, it'll support them all." But then, this is really just doing what the author advocates, privately, within your team, before releasing the API.
- thwarted 14y agoIt's amazing how many people consider dogfooding, before going public, to be a waste of time. Not only do you discover a whole bunch of bugs and difficult uses you didn't anticipate, it ends up being stronger when the public or partners are eventually let loose on it. The internet is rife with v1 APIs that don't have version designators and are deprecated in favor of a version two that was released to "clean things up" but which never really supplanted the version one.
- lquist 14y agoanother very important exception: crypto