This is the most accurate answer I've seen here (in terms of how Fielding described it).
The way he defines it in the dissertation is as a series of architectural constraints which evoke certain properties [1]. Those constraints are titled with "Client-Server", "Stateless", "Cache", "Uniform Interface", "Layered System", and "Code-On-Demand".
Your description of link relations is also correct. Links are the basis of all REST interoperation, whether for humans or APIs. I've been evangelizing the use of the Link header [2], which benefits from
1) a standard format regardless of content-type
2) the ability to be fetched with HEAD
3) the "relation type", which can be used to make strong assumptions about the endpoint
The way he defines it in the dissertation is as a series of architectural constraints which evoke certain properties [1]. Those constraints are titled with "Client-Server", "Stateless", "Cache", "Uniform Interface", "Layered System", and "Code-On-Demand".
Your description of link relations is also correct. Links are the basis of all REST interoperation, whether for humans or APIs. I've been evangelizing the use of the Link header [2], which benefits from
1. https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...2. http://tools.ietf.org/html/rfc5988