4 ms·

"there's just far too much confusion about what REST means to rescue it" No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything a

"there's just far too much confusion about what REST means to rescue it" No, there is no confusing. REST is exactly what's in Roy Fielding's thesis. Anything as is derived from REST, often with dismal ends. RESTful, RESTlike, RESTish are weasel words designed to say something along the lines of 'It's REST, but with these additions', or 'It's REST, but with these constraints loosened', or a mix of both. I was there at the beginning of SOA in 2004 and SOA then was an amazingly useful concept that worked well. The term SOA was hijacked to mean so many things, often by consultants pitching their version of SOA enablement or training, and at a rapid pace. By 2009 the meaning of SOA was so buzzwordy and clouded that people were trying to invent new terms to refer to the original concept. If someone wants to create a new thing, create a new thing and give attribution to the shoulders you stand on (i.e., ABC is based on REST but is different in these ways..1,2,3).

tomnipotent 5y ago
SOA was overloaded even in 2004, when IBM was promoting it heavily. In 2021, it so inclusive that even microservices fall under its purview. > often by consultants pitching You do realize the term originated by consultants, like many other terms used today (DDD, Gang of Four, Agile, anything from Fowler/Martin etc.). Consultants may not always be the best at implementing things, but I've always found that they do a great job of giving names and marketing repeatable business/software processes.
- Communitivity 5y ago
  You're probably right. The Thomas Erl book came out in 2004, so it was popular at least a year before that. Btw, I am a consultant. As for implementing things - there are consultants that track toward the marketing/image side of the spectrum and there are those that track toward the shipping/substance side of the spectrum, as in all things. On naming you are spot on. Being good at naming things is almost a job requirement. I've been at larger companies where there were multiple training sessions on how to name things for marketing, and when to hire outside consultants to come up with the names. I was on one project where tech leadership was outspoken and stepped on some toes. They respun the projects concept slightly and changed the name to sidestep the animosity.
  - tomnipotent 5y ago
    I only remember the timing because I was at the MySpace parent company before/during its hypergrowth, so all sorts of architectural patterns were being discussed/evaluated/used. This was during a time when complaining about SOAP/XML was the trend, greybeards liked to remind the young'uns about the nightmares of COM/CORBA, and Domain-Driven Design and Patterns of Enterprise Application Architecture were the new shiny things. > As for implementing things That's on me, I took a cheap jab at consultants. I've worked with many great consultants, more often than not people I've worked with in the past that went independent (or someone they similarly worked with). > Being good at naming things is almost a job requirement I wish someone had told me that moving up the seniority ladder also meant more PowerPoints, presentations, and buzzwords. Every startup CEO I've worked with seems to fall for the allure of language, since they're now point person to investors and are expected to provide 12-16 hours of board meeting material a year. Finding succinct language to explain ideas that will likely cost millions of dollars is hard work. > changed the name to sidestep the animosity I had a boss that liked to tell me "Don't focus on getting more people talking louder about your idea, but to stay quiet so the loud few are heard". I didn't need to get people to love my ideas, just not speak out against them. Neutrality is sometimes just as good as an endorsement, and that's doubly true with engineering work when you're usually trying to convince non-or-slightly technical peers to invest in your recommendations.
    - Communitivity 5y ago
      > greybeards liked to remind the young'uns about the nightmares of COM/CORBA Yeah, I dealt with COM/CORBA at its tail end too. It was horrible, but could be made to work. Was forced to use it as a key piece in a collaborative testbed and simulation framework running and communicating at 4 research centers (UK, US east, US west, AUS). > a cheap jab at consultants Understandable, I'm among the first to admit many consultants deserve it. One time a co-worker and I travelled from NY to our corporate mothership in VA for meetings. We got there and our first meeting was delayed. I took out my laptop and started working, trying to get some code in while we waited. My coworker took out his newspaper and read that. Same coworker told me 'He always makes sure he comes out ahead on expenses.' > moving up the seniority ladder also meant more PowerPoints, presentations, and buzzwords. I hear that. I get to code maybe 20% of my time now as a tech lead on a bigger project. Previous tech lead positions were on small projects where everyone needed to code as well as wear their other hats. It's a step up in pay and, in a way, impact, but I question whether I like it. I may stay pure technical. I am at least getting to code Rust in my personal time. > get people to love my ideas, just not speak out against them I wish more people knew that. We tried to convert people to the OASIS XDI specification, but I think W3C and others saw it as a rejection of their approach. Arguing with them to convert them just made them more vocal in their objections and eventually the standard's ratification failed. Was a decent spec, though it did need a fair bit of supporting specs still.

tomnipotent 5y ago

SOA was overloaded even in 2004, when IBM was promoting it heavily. In 2021, it so inclusive that even microservices fall under its purview. > often by consultants pitching You do realize the term originated by consultants, like many other terms used today (DDD, Gang of Four, Agile, anything from Fowler/Martin etc.). Consultants may not always be the best at implementing things, but I've always found that they do a great job of giving names and marketing repeatable business/software processes.

Communitivity 5y ago
You're probably right. The Thomas Erl book came out in 2004, so it was popular at least a year before that. Btw, I am a consultant. As for implementing things - there are consultants that track toward the marketing/image side of the spectrum and there are those that track toward the shipping/substance side of the spectrum, as in all things. On naming you are spot on. Being good at naming things is almost a job requirement. I've been at larger companies where there were multiple training sessions on how to name things for marketing, and when to hire outside consultants to come up with the names. I was on one project where tech leadership was outspoken and stepped on some toes. They respun the projects concept slightly and changed the name to sidestep the animosity.
- tomnipotent 5y ago
  I only remember the timing because I was at the MySpace parent company before/during its hypergrowth, so all sorts of architectural patterns were being discussed/evaluated/used. This was during a time when complaining about SOAP/XML was the trend, greybeards liked to remind the young'uns about the nightmares of COM/CORBA, and Domain-Driven Design and Patterns of Enterprise Application Architecture were the new shiny things. > As for implementing things That's on me, I took a cheap jab at consultants. I've worked with many great consultants, more often than not people I've worked with in the past that went independent (or someone they similarly worked with). > Being good at naming things is almost a job requirement I wish someone had told me that moving up the seniority ladder also meant more PowerPoints, presentations, and buzzwords. Every startup CEO I've worked with seems to fall for the allure of language, since they're now point person to investors and are expected to provide 12-16 hours of board meeting material a year. Finding succinct language to explain ideas that will likely cost millions of dollars is hard work. > changed the name to sidestep the animosity I had a boss that liked to tell me "Don't focus on getting more people talking louder about your idea, but to stay quiet so the loud few are heard". I didn't need to get people to love my ideas, just not speak out against them. Neutrality is sometimes just as good as an endorsement, and that's doubly true with engineering work when you're usually trying to convince non-or-slightly technical peers to invest in your recommendations.
  - Communitivity 5y ago
    > greybeards liked to remind the young'uns about the nightmares of COM/CORBA Yeah, I dealt with COM/CORBA at its tail end too. It was horrible, but could be made to work. Was forced to use it as a key piece in a collaborative testbed and simulation framework running and communicating at 4 research centers (UK, US east, US west, AUS). > a cheap jab at consultants Understandable, I'm among the first to admit many consultants deserve it. One time a co-worker and I travelled from NY to our corporate mothership in VA for meetings. We got there and our first meeting was delayed. I took out my laptop and started working, trying to get some code in while we waited. My coworker took out his newspaper and read that. Same coworker told me 'He always makes sure he comes out ahead on expenses.' > moving up the seniority ladder also meant more PowerPoints, presentations, and buzzwords. I hear that. I get to code maybe 20% of my time now as a tech lead on a bigger project. Previous tech lead positions were on small projects where everyone needed to code as well as wear their other hats. It's a step up in pay and, in a way, impact, but I question whether I like it. I may stay pure technical. I am at least getting to code Rust in my personal time. > get people to love my ideas, just not speak out against them I wish more people knew that. We tried to convert people to the OASIS XDI specification, but I think W3C and others saw it as a rejection of their approach. Arguing with them to convert them just made them more vocal in their objections and eventually the standard's ratification failed. Was a decent spec, though it did need a fair bit of supporting specs still.