As we have seen in earlier sections, a resource represents a named entity in a web application, and it is usually a Uniform Resource Locator (URL). So, an entity can be identified and assigned as a resource by an explicit reference to it.

A URL in a web application is usually a link, and it is in fact a URI. For example, a home page URI, https://developer.twitter.com, uniquely identifies the concept of a specific website's root resource. In REST constraints, the URIs we use are described as follows:

• The semantics of the mapping of the URI to a resource must not change. For instance, Twitter's https://api.twitter.com/1.1/statuses/retweets/:id.json as a URI may never change, and of course the contents or values will keep improving, according to the latest updates.
• Resource identification is independent of its values so two resources could point to the same data at some point, but they are not the same resource.
• For example, URI 1, https://api.twitter.com/1.1/statuses/retweets/:id.json, returns a collection up to 100 of the most recent retweets of a tweet (specified by the ID).
• The other URI 2, https://api.twitter.com/1.1/statuses/retweeters/ids.json, responds with a collection of 100 user IDs (maximum) belonging to users who have retweeted the tweet (specified by the ID parameter).

• URIs bring benefits such as only one way to access a resource, dynamic media types for resource responses (serve the media type at the time it is requested) with the help of the Accept headers, and clients accessing those dynamic resources do not need to change any identifiers if any change is made in the response content type.