REST is everywhere in blog chatter, while many GWT teams still ship apps with classic RPC. If you are building a snappy front end on top of Java today, this choice shapes your server code and your day to day debugging.
GWT RPC feels like home for a Java shop. You write interfaces, share DTOs, click compile, and get type safe calls that feel like a method invoke across the wire. The client stub takes care of callbacks and serialization, so you move fast without juggling raw HTTP details. This is great for complex object graphs, custom serializers, and shared validation, since both sides speak the same language and you can refactor with your IDE without fear. The cost shows up when you need visibility at the wire level, because most calls end up as a POST with a custom payload that tools like curl or Firebug do not read easily. Version drift hurts too, as a mismatched serialization policy or a renamed field can break calls in a way that is hard to spot until production logs complain. You also give up easy browser caching since the payload is opaque and verbs are not used to signal intent.
REST in GWT means embracing GET, POST, PUT, and DELETE, plus predictable resource URLs and visible formats like JSON or XML. With RequestBuilder you can talk to endpoints that any script or device can read, and you can debug with your browser network panel, curl, or even a simple wget. Conditional requests with ETag or If-Modified-Since cut bandwidth and speed up repeat views, and shared proxies can cache results for free. You can stream small payloads, page results, and document your API with examples instead of generated stubs. The trade is that you now own mapping text payloads to client objects, usually with JavaScriptObject overlays or a JSON parser, and you need to watch the same origin policy since cross domain calls require JSONP or a tiny server proxy. Auth flows also change, since cookies and server sessions are easy with RPC, while token schemes and signed headers are more natural for REST.
So when should a GWT app pick one over the other. If you control both ends, have rich domain models, and want fast refactors with shared Java, GWT RPC is a sweet spot. It shines for internal tools, admin consoles, or apps where no one outside your team will ever call the service and where you want tight compile time help with every call. If your app needs public endpoints, mobile clients, or third party mashups, REST keeps you honest and portable, and it plays nicely with caches and proxies that already understand plain HTTP. It also helps with troubleshooting since a URL plus curl shows the whole story without custom viewers. A lot of teams mix both styles, with REST for resource reads and public tasks, and RPC for tricky write flows that rely on shared Java and rich validation, and that hybrid often lands the best uptime and the least surprise for everyone.
RPC feels like a straight shot to the database, but it can hide too much. Because many calls arrive as a POST with a blob payload, you skip the free stuff that HTTP gives you: idempotent reads, transparent caching, content negotiation, and intermediate proxies that make things faster for users who sit behind a corporate gateway. REST flips that, putting more on the client to parse and map, while the network and the browser do more for free. GWT helps with both paths today, but your choice affects build speed, test coverage, and how easy it is to stage and roll back. With RPC, a client and server must move together, or you risk serialization hiccups when only one side changes. With REST, you need to version your URLs or media types, keep response shapes steady, and be strict with error codes so the client knows what broke without a stack trace.
Let’s talk performance without buzzwords. RPC can be quick on the wire since the payload is compact and you can tune serializers, but it often defeats shared caches and turns every screen into a full round trip. REST can be just as quick when you cache smartly with ETag and only move diffs, and static resources near users help even more. Binary in RPC feels fast, yet parsing small JSON objects is plenty quick in today’s browsers and the win from conditional GETs can be huge. Tooling matters too, since Firebug, Chrome DevTools, and even simple server logs tell a lot more truth with REST than with a custom binary blob. And do not forget operations: tracing a single request through a proxy, a CDN, and a servlet is far kinder when each hop sees clear verbs and headers. Debug time is real life time, and clear wire formats cut the pain by half.
Pick the style that matches your audience and your runtime, then commit to it with clear rules.