I've almost exclusively seen this handled using an upload with a temporary filename (usually convention based) and then renamed on completion. Watch then for the existence of the renamed files. Clean up temp files after a defined amount to time (30 days for example).
Ahyes, smart. We didn't control the client, unfortunately, so we couldn't do that.
(we tried to communicate with the people who did but they turned out to be the supplier to the supplier to the customer of our customer, 5 countries away, and fixing anything at all was not high on their priority list :D)
Does it have to be node.js? Are you looking to expand your JS skills, or do you just want a decent static site generator? (If B, then hugo is awesome, and awesome fast)
Useful article for someone needing help in revising a URI naming scheme, but beyond that could end up being harmful to that person's greater understanding of building "RESTful" systems.
For example, in the Idempotency section, the author states that for GET requests "no change in application state should occur" which is good, but then also states "the response should always be the same" which is incorrect. There's nothing that says the response cant change, if the resource has changed, but the constraint is that it cant cant _as a result_ of the GET request. This is an important distinction.
DELETEing a resource twice, the second delete should be a NOOP, not a 404.
There's some excellent NDC Oslo & London talks covering more in-depth RESTful topics that I'd recommend checking out if the content of the article is an eye opener for you.
I'll second the comment about On-boarding, follow up templated emails just serve to annoy me. I'll try out the product when I get a chance to. Maybe a simple 24 hour later email introducing support and asking if I've got questions and another follow up 2 weeks later. Nothing more.
Oh and please please please, put some effort into multi-account detection (if not a side project). It's really annoying / unprofessional to trigger off a new series of On-boarding emails just because I added a new org.
Also, price appropriately, just because your unlimited plan is stupidly priced wont make people thing the solo plan is reasonable if it's not. Ask your early customers what they're using and what features they'd use/pay for if individually offered to them.
If you're a startup wasting your time working on some way to detect multiple accounts for people who really hate on boarding emails AND have multiples accounts, you're doomed. Just put a checkbox on the sign up form somewhere allowing the user to opt out of the on board flow and be done with it (if you even care that much - in general you should have much higher priorities or you've run out of things to work on).
They are also best avoided. Design for failure.