Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Indeed. Though I guess a better example would be: it'll go the same way as REST APIs (which happen to be fundamentally the same thing as MCP anyway).

Remember the time when REST was the new hot thing, everyone started doing API-first design, and people thought it'll empower people by letting programs navigate services for them programmatically? Remember when "mashups" were the future?

It all died before it could come to pass, because businesses quickly remembered that all their money comes specifically from denying users those capabilities.

View on HN

REST did not die. it mostly became a mechanism for business managers to separate concerns between frontend and backend.

i wonder if mcp will become, "let the project people talk to the backend team and the frontend team separately and the AI will figure out the middle"

This is already the way my company wants to go.

Put MCP in front of every GET API, and let teams explore on their own

> and people thought it'll empower people by letting programs navigate services for them programmatically?

I don’t think that concept died because of nefarious business-related reasons but rather that building true HATEOAS APIs is hard and the utility of “automatically navigable APIs” is quite limited. It’s a neat trick to point a generic API client at an API and crawl it automatically, but hardly anyone consumes APIs that way. We read the API docs and construct integrations suited to the task at hand, manually.

Right. But there are hardly any useful APIs you can just use, with only an account on a service and willingness to read the docs. Everyone is exposing as little functionality as possible, and even that only under special conditions that make them useless for regular people. APIs are primarily a way for businesses to partner these days.

I don't know about that. Zapier and automation apps were huge before agents, or even for integrations for Slack. There is definitely a big portion of tech products that have mutual benefits by providing good APIs to be in the same bubble

Yes, that's my point - Zapier is exactly where this is heading. Automation as a service, requiring you to enter into contracts with everyone, and limited only to what said services feel like enabling. This is the opposite of what we hoped APIs will be, and the opposite of what people hope MCP will be.

How is MCP doing the same as REST?

I’m a REST developer learning MCP, and most of my effort is spent finding anything new to learn.

So I’m not suprised by this statement, but I’m a bit startled.

How are they the same thing?

REST and MCP aren’t fundamentally the same thing. MCP is JSON-RPC, and includes special methods that allow you to enumerate the various functions and their signatures. REST apis have none of that, and use different verbs. JSON-RPC is always POST (which kills cacheability for common reads, unfortunately).

Reply on news.ycombinator.com