This may seem obvious on the surface, but architects, developers, and product managers ask me this question all the time. Not that they don’t understand the concept, but rather the practical application. It does not help that the buzz-term “Resource Oriented Architecture” has started to take hold, mostly with vendor-advantage making definitions and capabilities.
It also does not help that so many have written on the compatibility of, differences between, and utility of SOA and ROA. Ultimately, these are orthogonal concepts and should not be thought of as an either-or equation (more on that in a future post, perhaps).
So, what is a Resource then? The answer is somewhat unsatisfactory for many… it depends.
In the abstract, the definition of a Resource is clear, though a bit conceptual, as proposed by Fielding in his now famous dissertation. The initial definition Fielding gives for Resource:
The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. “today’s weather in Los Angeles”), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author’s hypertext reference must fit within the definition of a resource. A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time.
Fielding goes on to clarify what is meant by this, but the bottom line is, what the Resources are in your system depends on the intersection of the domain of the system and the user stories for interoperating with the information (Resources) provided by the system.
Start with the demand for information and how it is used, then work down from there to derive what the Resources are for your system. Think in terms of reusable information products, and examine how they are composed- look for opportunities to use finer grained Resources that can be composed. This will lead to your What is a Resource for your system.
For example, in the banking/finance world, one might model a “transaction” as a Resource, but in other industries, the concept of “transaction” may be more closely aligned with a process that occurs on information rather than as an information entity.
As with many things in the world of software and technology, there is likely no single perfectly correct way to model Resources for a given system. A Resource is after all, an abstraction, a model that reflects our understanding of a given system at a point in time.