1. Dumb terminals never really left us. They are in active use all over.
2. The current web trend is using more of the browser CPU, as opposed to the server CPU. Heck, I have entire apps that don't call the server after load at all. I don't remember being able to execute code in a dumb terminal (possibly you could...I just don't remember it).
Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.
I agree there are some problems with the ui, but at the same time the number of devices they design for is quite large (desktop web, mobile phone, set-top boxes, Apple TV, Google TV, Amazon TV, etc). Creating a UI that is consistent between all of them must be a bit daunting.
I remember hearing a story (probably apocryphal) of one of the armed forces trying to use image recognition to identify tanks. So the took a bunch of scenery pictures with and without tanks, then fed those pictures to the computer.
After some processing the computer was identifying pictures of tanks with 100% accuracy. So the group started showing off the software. Some guy proceeded to take a picture outside that had a tank in it, then fed that picture to the software. No tank found. More images given, more problems found.
So the group went back and look at the their tank image stockpile. All the pictures without tanks were taken in the morning, all the pictures with tanks in the afternoon.
When they thought they were training the software in identifying tanks, really it was identifying time of day.
I just want to point out something that might be relevant, namely that as a combat vet, I learned that adrenaline is a drug like no other, and it's also extremely addictive. A key point that many adventure seekers fail to take into account, and I think it can sometimes adversely affect their analysis of situations at the moment of truth. Always be prepared to call something like this off, up to the very last moment, don't let the excitement or pressure overcome the logical side of things.
I was laid off during 2002, during the peak of the dotcom bubble burst. Effectively I was out of work for 3 months, but didn't find full-time work for 9 months. I ended up having to borrow money from my parents to make ends meet (all payed back now).
At the time, I was very well versed in Delphi and was pretty good with C#, SQL, MDX, and various web technologies.
I spent my morning looking for new jobs, then in the afternoon I was writing my own MDX library for .Net (MDX is the Microsoft Analysis Services language/API). Eventually I was hired on by a contracting firm where I stayed for about 4 years.
My Take aways: My best advice is to stay connected with the community. Find a developer group that meets regularly, attend and present. I also learned I suck at running my own business.
I used to live in Michigan...burritos were terrible there. I seriously thought the entire midwest had burrito blite. I also spent a lot of time around Bemidji many years go, I don't remember seeing a burrito there.
Hopefully you are right and Minneapolis is better. But for my money Phoenix has some great burritos (I don't live there, I'm in Boise)
I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful.
We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us).
Now, POSTs can also be cached, but there are easy ways around it...you can do the same thing with a GET, but that means adding more information to the url.
Anyway, one we got to the point of forgoing all GET requests, we ended up just doing everything with a POST for simplicity.
Yeah, REST is nice for some things, but for normal APIs, you're calling them from a programming language, so calling remote functions (RPC) is very similar conceptually to calling local functions. You might not be able to guess the paths as easily as REST(?) but then again trying to make things REST style doesn't always work out when the things don't allow all the REST verbs or don't fit into a hierarchy, etc.
For serving a filesystem over HTTP REST is great though. And all that caching stuff comes in handy.
From a practical API standpoint though, having two different encodings (GET in url with url parameter encoding, and POST with form encoded or JSON) is a pain and has caused a number of minor bugs and definitely extra work.
Using HTTP is basically a socket for JSON RPC style calls is I think the most straightforward route. In this you have one RPC per request, POST only, with a JSON request body and JSON response. If you use keep-alive it's similar to a socket but can go through some firewalls a bit easier, and has a built-in framing format and metadata thing. Also it works with existing log monitoring tools and frameworks.