> for example, we used tx.update for both inserting and updating entities, but LLMs kept writing tx.create instead. Guess what: we now have tx.create, too.
If a function can both insert and update, it should be called "put". Using "update" is misleading.
Implement all of them, with slightly different edge cases that result in glaringly obvious RCE when two or three of them are misused in place of each other.
(New startup pitch: Our agentic AI scans your access and error logs, and automatically vibe codes new API endpoints for failed API calls and pushes them to production within seconds, all without expensive developers or human intervention! Please form an orderly queue with your termsheets and Angel Investment cheques.)
I wrote some joke code long ago for a library that does everything. You wrap all function calls in a try that submits the entire script as a bug report. The animatedBackgroundWithUnicorns() is then implemented.. eh i mean the bug is fixed.
It might actually work if the subscription is expensive enough.
... it depends on how the given server defines PUT of course (also how we define upsert, and does upsert make sense outside a DB setting? well, of course some DBs have a HTTP/ReST API.)
that said, usually PUT is meaningful for a URL (or URI), and in these circumstances it's like upsert, and it cannot blow away other keys, as it operates on one key, given by the URL
of course if we assume a batch endpoint, sure, it then can do non-upsert-like things
If a function can both insert and update, it should be called "put". Using "update" is misleading.