REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this.
To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again?
After 12+ years I'm just not sure anymore. If I'm using REST incorrectly (according to this article or others), but getting good results and everyone on the team is aligned, does it matter? I'm willing to have my mind changed this, maybe I'm missing something important
I try not to blame the 'Roy Fielding is right' camp on this. I also try not to blame the "terminology doesn't matter' camp.
There are groups of people using the same terms for different things, and getting into arguments where there could be agreement.
There's a diverse set of people on the spectrum between formally trained and self taught people in software development. Terms can get borrowed from places like academic research and get (mis)applied before they are understood.
The REST in industry software is essentially JSON RPC (no, not that one) mapped to HTTP methods. That's a mouthful, so people just say RESTful, despite it not quite being RESTful according to the original notion of REST.
Yes, industry-RESTful isn't necessarily RESTful according to original Roy Fielding definition, but trying to redefine a widely used industry term is unlikely to win one friends at dinner parties.
I think the problem is primarily if you publish a REST api for commercial consumption on some level. If people depend on your REST api, the "RESTfulness" of it affords you some level of inaccuracy when documenting how things work.
But that said, I'm okay with it not following the spec as long as things are clearly documented to end users. We just went through an issue where a prominent CDN provider exposing a REST API we depend on broke REST in a very important way (i.e. NOT stateless). It's extremely annoying to try and construct clients around nonstandard APIs, and the more REST-y, the less annoying.
Sure, ideally, but if no one can agree on the spec (as evidenced by the need for these types of articles,) then it's not really saving me much effort is it?
Better to just pick something and go with it, then argue about the spec more
> REST seems to bring out people who like to define specs and correct others on following the spec or not. There are many other things in tech like this.
Yes, and this blog post is exactly yet another example. Some of the blogger's points are blatant violations of REST, such as the comments on URIs and api versioning. Yet, the blogger elevates their own personal misconceptions to the status of one true RESTful way.
Ultimately it's all mostly irrelevant. All it matters is that the contract is specified and preserved and clients can consume services through a specific interface. Furthermore the pervasive use of openapi specs already crystalize the RPC approach to interfaces.
I keep running into this as well. Someone shared a link to a study from last year telling me that AI doesn't make programmers as productive as they think. The study was obviously done months prior to it's release. So evaluating the state AI even further back.
But this didn't seem to concern them. The study said X, therefore it applies to today.
I'm just not sure it's worth it to argue with others about it at this point. Not that I'm 100% all behind AI coding, but I'm just shocked people are still this resistant.
> I'm just not sure it's worth it to argue with others about it at this point.
This is the correct response. Let closed-minded people do their thing. Makes them less competitive against you. There's nothing for you to gain by trying to help them understand what they are missing.
I don't think you're going to get many "true" answers to this. The opportunity cost of not using the latest and best models is just too much right now.
Every month I research this and come to the same conclusion: the time, effort, and cost required to get local models (and the coding tools around them) to perform even close to Claude Code with sonnet/opus just not worth it right now. If it was, it would be distributive enough to be in the news.
Not that I'm discounting someone hasn't already solved this, just trying to Occam razor my way out of diving too deep down rabbit holes.
At some point, there will come a saturation point for that "Opportunity cost FOMO train ride", and I think we are already past that point. Mythos class models are a whole different beasts and cutting edge on reasoning but not much use for the problem domains most developers are trying to solve.
The present Sonnet/Opus versions (~4.8) will likely be what everyone in the enterprise might end up using eventually. And even though local models aren't there yet, there are budget alternatives from the families of DeepSeek, Kimi, GPT, MiniMax, etc. available through APIs of NVidida, OpenRouter, Groq, etc. which are very much Sonnet grade.
Personally, I don't think we're at that point yet. While I do think model improvement is starting to plateau (reaching a local ceiling), I'm not convinced local models are as good as sonnet/opus yet. The gap is still too much. But I'm excited for those models to reach those levels.
But you're pretty much measuring opportunity cost in tokens per second, no?
I think it strongly remains to be seen whether e.g. tokens per second (multiplied or whatever by percieved quality of private model) actually means "better or more useful output."
I strongly suspect it does not. (though I also strongly suspect this will be very difficult to measure because the incentive to lie about metrics here will be so strong.)
If you’re arguing that model metrics don’t necessarily translate into useful output, I agree. That’s not how I measure the success of a mode and not really the point I'm trying to make. I try to set things up and test it on my actual projects.
What I’m saying is that if local models were actually comparable to Claude Code in practice, we wouldn’t be having threads like this. It would be obvious to the people using them, and it would be massively disruptive. Why would individuals and companies pay hundreds or thousands for Claude Code if they could run something locally and consistently get similar results?
Every month I revisit the local ecosystem hoping the answer has changed. So far, my experience has been that it hasn’t.
Having, e.g. seen Microsoft maintain a monopoly for well over a decade, there's nothing in my experience that suggests that "quality always beats hype" is remotely true.
It's entirely possible Claude is just winning the hype game.
Microsoft have not maintained a monopoly on search, mobile, or maps, and they seem to mostly maintain their large market segments based on familiarity, not hype.
I think they are referring to the opportunity cost of time saved on doing things a local model cannot do or fixing it's mistakes against the cost of a subscription
I've got a machine in a corner collecting dust that cost me $12k to build 2 years ago. It runs fine but it's wildly impractical to use as a daily driver (loud/hot). I keep it as a reminder to not do this again.
At my current pace it would take me until sometime late 2030 to spend the same amount in gpt5.5 tokens.
You forget that, especially on HN, many people are scaremongering that prices will soon skyrocket. Then it will be another story... I easily run $4k+/mo on my claude sub; if I would have to pay that, I definitely would spend 12k on hardware instead and accept a dumber helper.
You are not stuck between public API pricing for frontier models via Claude and self hosted.
Remember that there are other LLM providers, open models, and previous gen models, that are way cheaper that frontier Claude and still way better than what can realistically run locally
Sounds like a correct conclusion to me also. I am trying to transition to a layered system: local, then OpenCode with commercial vendor APIs for models like DeepSeek v4 flash, then DeepSeek v4 Pro.
With a layered approach we can slowly shift to running more locally and still get required work done. Really, my local setup is so much better than it was 2 months ago, and extremely better than 6 months ago - on the same hardware.
This seems to be the answer. Building a rig with a decent graphics card will cost $2k+ and will produce sub-par results. Might as well milk the $100/m Claude sub until open-source alternatives reach parity with today's frontier models.
If you truly believe that it WILL get there within the next couple of years, then you might as well start playing with it now (and, yes, you will be very surprised, especially for shorter/smaller projects or nicely modularized larger projects)
that's super contextually dependent. I use them just as essentially a decompress of what I already know that I'm doing. I legitimately use 4B models just fine. I've got a large number of tools that make this entirely feasible and a daily driver for me (like https://github.com/day50-dev/llm-manpage-tool) ...
It's not really a bitter lesson here, I can scale those 4B models easier than someone can scale their 1000B models.
I wonder how long until Claude/OpenAI eat a lot of the current AI/Agent SaaS's lunch.
Originally I thought they would stick towards being a model provider mainly, but with all the recent releases it seems they do want to provide more "services."
Wonder what part of the market 3rd party apps will build a moat around?
I cloned a product today that does the 20% of a product my client needed. It took 8 hours and will save my client 2k a month in licensing fees. Plus, I can now add the features they were missing in the original product.
There's a lot of money to be made in small business automation right now.
Enterprise contracts almost always include a platform fee on top of per-seat costs (67% of contracts), plus professional services that add 12–18% of first-year revenue.
So for a lot of companies, it's worth using AI to create a replacement.
> So for a lot of companies, it's worth using AI to create a replacement.
I'll add the nuance that those might be big companies with slack capacity, or at least firms that already are at a point in their effort/performance curve where marginal effort injections in their core business are not worthy enough (a point that, without being big companies, would be actually weird). Even with AI and as processes become more efficient effort is at premium, and depending on your firm situation an man-hour used in your business might be a better use of effort and time that using it on non-core services.
Interesting, so you're saying Anthropic/Openai/etc will get a general solution that won't be hands off. The moat for other companies will be creating the specific, managed solution.
I can see that, assuming models don't make some giant leap forward.
> Fundamentals of Physics by Halliday, Resnick, Walker
I strongly recommend this textbook. I used in college, and it's really good. There are a lot of problems for each chapter, I suggest doing them as they help a lot.
It's kinda wild to take something people really like and just keep re-writing it while keeping the same name.
They were around when Angular 1 -> Angular 2 right? No one liked that. Angular 2 is good but calling it Angular 2 when it was so different put a bad taste in everyone's mouth.
Google did that because they wanted the Angular userbase, but that alienated a bunch devs and many decided to switch to React (me included) instead.
Seems the remix/react router team is trying to do the same. They built something popular, and they want to use that to launch their new ideas.
They want to have their cake and eat it too, a built in userbase and explore new ideas. I get it, but why not use another name so people don't get confused or frustrated?
> Google did that because they wanted the Angular userbase
I'm okay with that, because when it came out I was considered part of the Angular workforce, so I was hired to work with a framework I knew very little about at the time.
These guys are really, really obsessed with download counts. They brag a lot about that in twitter every time they have a chance.
What they want to reuse is the package name.
So now they launch whatever bullshit they are playing with now under the “remix” package and the next day they’ll say “look… we have N thousands downloads per second!!! We are so successful”
They did this multiple times. And will keep doing it because they are obsessed with this.
After ChatGPT Atlas came out I thought it would be fun to find UI patterns that AI browsers couldn't figure out like multiple download buttons, hidden unsubscribe buttons, etc. So I created 7 levels of web dark patterns for AI browsers. You can try it yourself if you want:
I found Atlas can get through most patterns, so I created an even more unhinged one (job application form) that shifts the interface and flashes content.
Don't take it too seriously as actually testing AI browsers, it just a fun side project. I documented the patterns here: https://codinhood.com/anti-ai-ui/about
AI seems obvious, but social video? Are they saying people watch TikToks instead of reading Wikipedia, or people who used to look things up don’t bother anymore because of TikTok?
I'm sure they do. Is that their primary source? Do they use nothing else? Is any of that information put to economic use in their lives or is it just curiosity?
The line of questioning was about news and knowledge, not ads. Ads in anything will affect people's purchases, so that's not evidence for what that question was actually going for.
> This distinction is important. Sometimes, creating a separate service is the scrappy thing to do, sometimes creating a monolith is. Sometimes not creating anything is the way to go.
I think this hits the nail on the head. People are trying to find the "one true way" for microservices vs monoliths. But it doesn't exist. It's context dependent.
It's like the DRY vs code duplication conversation. Trying to dictate that you will never duplicate code is a fool's errand, in the same way that duplicating code whenever something is slightly different is foolish.
To be honest, I just kind of don't understand the point. Could my API be better following some of these rules the author presented? Probably. But by how much? Is it worth it? When someone else on my team disagrees do we go back and argue about the spec again?
After 12+ years I'm just not sure anymore. If I'm using REST incorrectly (according to this article or others), but getting good results and everyone on the team is aligned, does it matter? I'm willing to have my mind changed this, maybe I'm missing something important