SWT is RESTful

According to the recent O'Reilly book RESTful Web Services, REST is a set of design criteria that are very general, and not particularly tied to the Web.

Nothing about REST depends on the mechanics of HTTP or the structure of URIs

One of the main criteria for a RESTful architecture is having a unified API regardless of which business problem is being solved. For example, HTTP is known for having the operations put, post, get, delete, and a few others. As long as it is used in that way, the application architecture is RESTful because its API is predictable regardless of the use cases.

I saw JavaBeans cited as an example. After all, every JavaBean can be introspected for available properties, and then you can always perform a set or a get on a particular property.

What is the benefit of this? Well, for HTTP, it enables all web browsers and different clients to work with RESTful web services (though browsers are generally limited to the get and post operations) For JavaBean, all Java tooling applications can work with any JavaBean without having to learn its particular API.

That brings me to SWT as an example. My colleague from a previous project, David Orme, always emphasized that SWT widgets must have a constructor that takes (parent, style) arguments. In fact, this is strongly recommended even for building custom widgets. Why? Because, this is what most SWT automated tools expect, such as the Visual Editor, and other GUI building tools. So, to make custom widgets usable by the widest range of clients, they better follow the same design in their constructor.

In conclusion, I would say that SWT is RESTful in the same way HTTP and JavaBeans API are.