A reasonable question about any platform offering three API styles is whether two of them are marketing. They are not, and the difference between them is not taste. Each is the right shape for a different question, and the cost of using the wrong one is paid in round trips.
No benchmark numbers appear below. Every claim here is arithmetic or architecture, which is the only kind of performance argument we are in a position to make honestly.
REST answers "what is the state of this thing"
One resource, one request. List the tools, fetch one tool, connect it, acknowledge an alarm. It is the right shape for configuration and for actions, it caches, and every engineer you will ever hire already knows it.
Where it stops being the right shape is composition. A board showing six tools, each with live state and its active alarms, is one request for the list and then one per tool. That is the N+1 pattern, and on a fleet it is not a style question.
The arithmetic that makes N+1 a real constraint
Our gateway ships with a default rate limit of sixty requests per minute per client. That is not a small number picked to be awkward, it is roughly what a fab API should tolerate from one dashboard.
Now count. Six tools composed client-side is seven requests per refresh. Refresh every ten seconds and you are at forty-two requests per minute, most of the budget, for six tools. Fifty tools cannot be served that way at any refresh interval worth having.
The fix is not a higher rate limit. The fix is needing fewer requests.
GraphQL answers "give me this shape"
One request, one response, the shape the screen actually needs. The board above, in GraphQL, is one query regardless of whether it covers six tools or fifty. The 1 + N becomes 1.
That is not a benchmark, it is counting. It is also why the same board that works on a demo bench keeps working when the fleet grows, which is the failure mode you want to avoid discovering in month four.
The second thing GraphQL buys is over-fetching. A REST endpoint returns its whole resource. A phone on a cellular link that needs a tool's name and alarm count does not want its serial timers, its session id and its full configuration. GraphQL asks for two fields and gets two fields.
WebSocket answers "tell me when it changes"
The other two are questions. This is a subscription.
Polling for alarms puts you between two bad options. Poll often and you spend your request budget asking a question whose answer is almost always "nothing has changed". Poll rarely and you find out late, which for an alarm is the entire problem.
A push feed removes the trade. The tool raises S5F1, the alarm reaches whatever is listening, and nothing polled anything. Your request budget stays free for the questions that actually need asking.
It also changes what is buildable. Escalation rules, live boards and anything that should react rather than report are natural against a push feed and awkward against a poll loop.
Where the savings actually are
It is tempting to put a percentage here. We will not, because we have not measured one and the honest version is more useful anyway.
Engineering time. The cost of a SECS/GEM integration is rarely the connection. It is a team learning a protocol family, HSMS session management, SECS-II item encoding, GEM state machines and the GEM300 standards on top, before writing a line of the thing they were actually asked to build. Against an HTTP API that work is not reduced, it is not done at all. Whether that is worth money to you depends on what your engineers cost and what else they could be doing, which are numbers you have and we do not.
Schedule. Integration work that can only start when the tool lands is on the critical path by construction. Work that can start against a simulator months earlier is not. That is a scheduling change, not a speed-up, and scheduling changes are usually worth more.
Rework. An interface that composes in one request does not need re-architecting when the fleet grows. The version of this that hurts is the one where the pilot works, the rollout doubles the tool count, and the dashboard starts hitting rate limits.
Choosing, in one line each
- REST when you want one thing, or want to do one thing. Configuration, actions, anything a cache helps.
- GraphQL when one screen needs several things at once, or a constrained client needs a few fields out of a large resource.
- WebSocket when the interesting moment is a change, and finding out late is the failure.
Most real integrations use all three, and the split usually falls out naturally: REST to set things up, GraphQL for the views, WebSocket for everything that should react.
The honest boundary
All three interfaces are implemented and exercised against our own equipment simulator. None has run against physical semiconductor equipment, and we publish no latency, throughput or uptime figures because none has been benchmarked.
The request arithmetic above is exactly that: arithmetic. Seven requests is seven requests and one query is one query, on any hardware. We would rather give you a number you can verify by counting than one you have to take on trust.