I'm planning to deliver an API as a web-service. When I update my API's (interpreted) code-base, however, I anticipate possibly needing to restart the API service or even just have a period where the code is being overwritten. This introduces the possibility that incoming API requests may be dropped or, even worse, that processes triggered by the API may be interrupted.
The flask library for python appears to offer something of a solution; by enabling debug mode it will check the modified flag on all python files and, for each request, it will reload any modules that have changed. It's not the performance penalty that puts me off this approach - it's the idea that it looks slightly jilted.
Surely there is an elegant, high-availability approach to what must be a common issue?
Edit: As @piotrek answered below, "there is no silver bullet". One briefly visible comment suggested using DNS to switch to a new API server after an update.
actually there is no silver bullet. you mention two different things. one is availability. it depends on how many nines you want to have in your 9,999... availability. second thing is api change. so:

availability:
some technologies allows you to do hot changes/deloyments. which means pending requests goes the old path, new request goes the new path. if your technology don't support it you can't use it for othe reasons, there are other options

in small scale intranet applications you simply don't care. you stop the world: stop the application, upload new version and start. on application stop many web frameworks stop accepting new connection and wait until all pending requests are finished. if yours don't support it you have 2 options: 

ignore it (db will rollback current transaction, user will get error)
implement it yourself (may be challenging).

and you do your best to shorten the inactivity period. 
if you can't afford to stop everything then you can do:

clustering. restart one service by one. all the time some server is available. that's not always possible because sometimes you have to change your database and not always you can do it on working system or you can't afford to loose any data in case of update failure
microservices. if you split your application into many independent components connected with persistent queues then you turn of only some parts of your system (graceful degradation). for example you can disable component that writes changes to the database but still allow reads. if you have infrastructure to do it quickly then the update may be unnoticed - requests will be put into queues and picked up by new version


api change:
you version your api. each request says which version it requires. 

if you control all your clients / small scale / decide not to support old versions : you don't care. everyone has to update its client.
if not, then again microservices may help. you split your public api from internal api. and you keep all your public api services running and announce then some of them are deprecated. you monitor their usage. when you decide that usage of some version is low enough you announce end-of-life and later you shutdown specific version


that's best i've got for the moment
How do I design an API such that code updates don't cause interruptions?