Lots of discussion of #REST APIs tends to focus on things like hyperlinks (“HATEOAS”), or uniform interface, which are interesting topics for sure. But when I first heard about REST it blew my mind for entirely different reasons that seem rarely if ever discussed these days.
Like most programmers of my generation (and still now) I was taught OO as the way to write software: Stateful objects that you send messages to and which update their own state (which they keep hidden/encapsulated). When I thought about a remote API then it was natural to keep this world model: stateful objects on the server that you send messages to to update. All that mattered then was finding a good syntax for those messages.
REST completely flipped this on its head. Rather than the client sending messages to the server to perform actions on stateful objects, you instead sent (a representation of) the entire state of the object to the client. The client then updated it to the desired state and sent (a representation of) the final state back to the server. REpresentational State Transfer. That’s literally what it means.
Over 20 years on, I still find this vision astoundingly radical.
As a sometime 'C', Java, C#, VB, VBA and PL/SQL programmer, I have never liked the concept of OO programming. It has always seemed to me that it obstructs rather than helps good programming! As a measure to stop programmers abusing global variables, it's massive overkill and it most certainly does not facilitate good programming practice!
However, as in all things in life, that which was the case when one started doing a particular task is what is normal, according to our brains. Thus, if you were raised on 00 programming languages, you will consider that to be the right and proper way to write code. The first language I learned was “C”; A very flexible language with nothing to impede bad programming habits other than self-discipline which I was taught alongside the language itself!
This all reminds me of a chap who applied for a post as a Visual Basic 3 programmer at a company where I once worked. He passed the interview by demonstrating most convincingly that he was the type who would fit into the team, he also passed the technical interview with flying colours and so the company made him an offer. Not satisfied with being offered the job, he insisted on sending the head of the programming team some of his code for informal review before starting work. The code he sent was an absolute horror story; it was littered with “GoTo”s making it almost unintelligible by modern standards and certainly not the sort of code the company wanted their programmers to produce. The offer of employment was swiftly withdrawn!
The “GoTo” instruction exists in most modern programming languages but everyone who learns to programme in a formal teaching environment is taught never to use it except in the most extreme circumstances when there is absolutely no other choice.
It has always seemed to me that object orientation was introduced to fix problems induced by indiscipline in coding practise and lack of rigorous code review.
@Paulos_the_fog OO means so many different things these days that I find it hard to have any firm opinions about it. As Alan Kay said, the emphasis should have been on messages rather than objects. I like the idea of Erlang as an instance of this vision: simple independent processes communicating via message passing. I also think that if you squint enough microservices can be seen as OO in this manner.
I can live without classes, inheritance, and all that stuff.