131–140 of 154 posts
"Misrepresentation of the REST architecture has spread so far and wide that "REST" has come to be informally understood as a synonym for "HTTP"."
Misrepresentation of OOP has spread so far and wide that "OOP" has come to be informally understood as a synonym for using class based languages.
This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…
This is all pedantry. I don't think I've ever talked to a developer who cares. All people care about is whether or not you have a sane API to work with over HTTP. It uses appropriate verbs, maybe, and has meaningful endpoints and request and response objects you work with, hopefully. You can make up a new acronym for it like "WNI" or Web Negotiation Interface, but it doesn't change anything that people care about. Th…
REST will be rebranded one day because our industry loves renaming old ideas and presenting them as new. I agree with you though, it's pointless.
I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification Super simple. I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.
I'll pass...
I've given up on REST and I build all my new APIs with JSON-RPC. https://www.jsonrpc.org/specification Super simple. I'm not a fan of the complexity things like gRPC introduce to most languages (the PHP tooling is horrible for example), and I really don't like the limitations of HTTP verbs and the box that trying to confirm to CRUD puts you in.
> Updated: 2013-01-04 I'll pass...
Earlier quoted context omitted.
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 g…
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 requir…
> 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.
Earlier quoted context omitted.
> It uses appropriate verbs... This shouldn't even be a thing to think about. HTTP verbs and error codes don't map well to many real use cases. You might argue that "GET" does map well to a query. However, you can't send a body with a GET, so you need to put that information in the URL, which is limited and causes other issues to consider. If we just admit that we're really doing RPC anyway, there is no point in usin…
As soon as you ignore HTTP constructs, you drop infrastructural benefits and the benefits of particular levels of abstraction reacting to those responses, which are often fully intended to be used. You can’t get frustrated that HTTP isn’t a raw socket. If you didn’t care about any of that you might as well use websockets for everything. And then as soon as you do, you lose out on everything that requires an HTTP requ…
Can you turn this word salad into a real world example? If it's "you can cache GET requests through a proxy" or something of the sort: Fine, use HTTP GET for that. You don't need to do absolutely everything through RPC. Obviously, a web client using RPC needs to be shipped through HTTP GET, for instance.
> If you didn’t care about any of that you might as well use websockets for everything. And then as soon as you do, you lose out on everything that requires an HTTP request/response.
No. I'm fine with using HTTP for RPC. I'm fine with request/response, it maps well to RPC. What I have a problem with is shoehorning RPC into HTTP verbs and codes for literally no benefit. That's what distinguishes "real world REST" from the more reasonable JSON-RPC.