# hypermedia Published articles for hypermedia. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Turning Hypermedia APIs into MCPs DevFeed: [Turning Hypermedia APIs into MCPs]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2025-09-18T09:00:00Z Content type: tutorial Language: en Sources: [Daniel Doubrovkine]() Topics: [API](), [Model Context Protocol (MCP)](), [MCP Server](), [REST API](), [Ruby](), [Open Source](), [Slack]() Tags: [ai](), [api-design](), [apis](), [hypermedia](), [mcp](), [mcp-server](), [mcps](), [model-context-protocol](), [open-source](), [rest](), [rest-api](), [ruby](), [slack]() ### AI overview This tutorial shows how to expose a Hypermedia API as an MCP server using the Ruby gem hyperclient-mcp. It uses the open-source S'Up Slack bot to demonstrate resource discovery, starting the server, connecting it to Claude, and querying bot and team information. ### Source excerpt I've written and talked extensively about Hypermedia APIs for about a decade. The HATEOAS constraints in representing resources for a RESTful API has numerous advantages in API design, readability, discoverability, and performance over a hand-rolled REST API. Unfortunately, adoption of Hypermedia APIs is very low compared to, for example GraphQL, but I find the implementation a lot simpler and continue adding Hypermedia APIs to my pet projects. At its root a Hypermedia API looks like so. { "_links": { "self": { "href": "https://sup2.playplay.io/api" }, "status": { "href": "https://sup2.playplay.io/api/status" }, "team": { "href": "https://sup2.playplay.io/api/teams/{id}", "templated": true }, ... } } The above example is an extract from this API. For this post we will use one of my Slack bots called S'Up, which generates fresh triads of team members in Slack to meet for coffee every week in an informal standup. The bot is open-source and you can try it here. Because the Hypermedia API structure is fixed with only "resources" and "links" (and similar to API frameworks such as GraphQL) you don't need an application-specific client to interact with the API. In Ruby, the most popular generic Hypermedia client is Hyperclient. With the API above, a client can retrieve the bot status, and using an API token obtained from an existing installation some team information. api = Hyperclient.new('https://sup2.playplay.io/api') do |client| client.headers['X-Access-Token'] = ENV.fetch('TOKEN', nil) end status = api.status puts "Bot is #{status.ping['presence']['presence']}." team = api.team(id: '1234') puts "Team name is '#{team.name}'." This will output "Bot is online." and "Team name is 'dblock'." for my installation. In this case, the generic client knew nothing about "team" - it was discovered programmatically and was, in a way, self-documenting. Unsurprisingly, this idea of templated resources is reused almost exactly the same way in the model context protocol (MCP). Therefor ## How your API could benefit from Hypermedia DevFeed: [How your API could benefit from Hypermedia]() Original publisher: [Read original article]() Author: Olivier Hervieu Published: 2015-04-23T13:15:46Z Content type: tutorial Language: en Sources: [eFounders]() Topics: [API](), [hypermedia](), [HTTP](), [Website](), [client]() Tags: [api](), [client](), [computer-science](), [http](), [hypermedia](), [links](), [rest](), [stateless](), [tech](), [web]() ### 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