Developer Thought Stream

There has been some debate about when to use PUT versus PATCH versus POST in REST APIs. Having dealt with a variety of 3rd-party REST APIs now, I've become a little opinionated about how the various methods *should* be used. Here's my take: The way I prefer to see PUT used is to submit a fully-formed replacement resource. In other words, if you are using PUT to update a resource, you probably will want to fetch the object from the resource initially, modify it and then PUT the entire modified object back to the resource.  If you are creating a new resource, use PUT only if you are creating your own resource ID (probably not a common use-case, since most resources will auto-assign their own IDs). In contrast, PATCH can update any number of properties of a known resource without needing to submit the entirety of the resource. In most cases, PATCH is the right method for updates as it saves on bandwidth. IMO, POST is the right method for creating a new resource, assuming IDs a...

I had an interesting conversation with some banking execs who had a lot to say about mobile-first design and multi-page "form wizards"...none of it good. What they told me was that when you are dealing with forms with lots of data (as loan applications tend to be), the last thing you want is to submit page after page of short, one-page forms. They were very adamant that these multi-page (they called them "tabbed") applications were killing their productivity. They want one REALLY BIG form with all the data on it that they can fill out once and submit. They don't care if they have to scroll a lot or if there are a lot of fields on the page. They went so far as to say it would shave hours off of their daily work and earn the bank loads of money. Interestingly, I'd always resisted mobile-friendly pages for business apps because my personal preference is to organize the data well so that you don't need a bunch of "submit" buttons. I feel l...