A resource is the thing that you are working with. For example, if you have an API for switching a certain lamp, then the resource is the lamp itself. A resource can be physical (e.g. lamp, person) or non physical (e.g. article, role, a row in the database), a resource can be primary (e.g. balance) or derived (e.g. transaction). A resource can refer to a specific entity (e.g. the fifth lamp installed in this lamp socket), or it can refer to a role that maps to different entity at different time (e.g. the currently installed lamp, the lamp installed on 5th August 2008) or it can map to multiple entities (e.g. all lamps in the house).
The representation of a resource is the way that your service communicates the state of the resource, e.g. XML, JSON that represents the state of the lamp.
In REST API, a resource is identified by a uniform identifier (e.g. URI). A single resource can have multiple representations, in HTTP REST API you'd normally indicate the representation you want to use in the HTTP Content-Type and Accept headers.
One key realizations in client server architecture is that you cannot bring the resource to the client, and you shouldn't try to make it like you do. Instead, in REST API, you remotely manipulate a resource by transferring representations of the resource. Think of this like, you don't FedEx the lamp so that the client can manipulate the lamp directly, but rather the service create an XML/JSON/protobuf/CSV representation of the lamp and the client send a representation of the intended manipulations. The service then manipulates the actual state of the lamp on behalf of the client, or reject the request, say if the client isn't authorized to do the operations on the lamp. This might seem obvious/splitting hair, but the important thing to note is that since the representation is not the resource itself, the representation can get out of date with the state of the resource.