# hypermedia

Hypermedia is an extension of hypertext that incorporates media beyond text and supports linking capabilities across information systems.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## How your API could benefit from Hypermedia

DevFeed: [How your API could benefit from Hypermedia](<https://devfeed.tech/articles/how-your-api-could-benefit-from-hypermedia-34699.md>)

Original publisher: [Read original article](<https://medium.com/unexpected-token/how-your-api-could-benefit-from-hypermedia-b62780771ccb?source=rss----2d2624499d2---4>)

Author: Olivier Hervieu

Published: 2015-04-23T13:15:46Z

Content type: tutorial

Language: en

Sources: [eFounders](<https://devfeed.tech/sources/efounders.md>)

Topics: [API](<https://devfeed.tech/topics/api.md>), [hypermedia](<https://devfeed.tech/topics/hypermedia.md>), [HTTP](<https://devfeed.tech/topics/http.md>), [Website](<https://devfeed.tech/topics/website.md>), [client](<https://devfeed.tech/topics/client.md>)

Tags: [api](<https://devfeed.tech/tags/api.md>), [client](<https://devfeed.tech/tags/client.md>), [computer-science](<https://devfeed.tech/tags/computer-science.md>), [http](<https://devfeed.tech/tags/http.md>), [hypermedia](<https://devfeed.tech/tags/hypermedia.md>), [links](<https://devfeed.tech/tags/links.md>), [rest](<https://devfeed.tech/tags/rest.md>), [stateless](<https://devfeed.tech/tags/stateless.md>), [tech](<https://devfeed.tech/tags/tech.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

The article explains how hypermedia supports the REST uniform interface constraint in APIs. It describes resource representations, self-descriptive messages, and server-provided hyperlinks that expose transitions and actions, using the web as an analogy and beginning a Twitter API example.

### Source excerpt

illustration by adrien griveau Roy Fielding's dissertation thesis on "Architectural Styles and the Design of Network-based Software Architectures" albeit published in 2000, is still a goldmine in 2015. For those who are not familiar with Fielding's work, he is one of the authors of the Apache web server, he has worked on the first specification of HTTP, and he is the father of the REST acronym. A REST architecture is an architecture that MUST (as in RFC 2119) respect the following architectural constraints: client-server stateless cacheable layered-system uniform interface code-on-demand (optionally) HTTP and the 2000's World Wide Web, fit perfectly in this description of a REST architecture (in fact, REST constraints seem to be chosen so that systems that would respect these constraints will look like the web ☺) 15 years later, everybody builds RESTful APIs. These APIs take full benefit from HTTP (and thus, from its REST-base architecture) but most APIs do not fully respect the "uniform interface" constraint. In the Fielding sense, an API is really RESTful if it respects the uniform interface constraints: resources are unambiguously requested via URIs, representations of resources are manipulated (you're always playing with a "view" of a resource, not the resource itself), messages are self-descriptive and self-contained, transitions and actions should be clearly exposed to the client by the server, via hyperlinks and hypertext. This point is often referred as HATEOS: Hypermedia as the engine of application state. A classical website, like the one from which you're reading this article, uses hypermedia as the engine of application state. You're viewing representations of resources and, on each of them, a set of actions (going back to home, viewing a related article) is actionable via hypertext links. Clicking on one of these links will (hopefully) give you another view of another resource, modifying the application state. Those links are materialized and explained