Exemplos reais de HATEOAS (arquitetura REST) ​​[fechado]

como todo mundo deve ter notado, existem muitas APIs REST falsas / rudimentares em estado selvagem (que implementam uma API HTTP e a chamam de REST sem seguir o requisito de hipertexto como o mecanismo do motor do aplicativo, o que levou ao famoso discurso de Roy T. Fielding , o homem que primeiro especificou o paradigma REST).

Não consegui encontrar nenhum exemplo prático de uma implementação REST verdadeiramente orientada por hipertexto, juntamente com as definições de tipo de mídia específicas do aplicativo associadas para as transições de estado.

Existem exemplos publicamente acessíveis de tais implementações?

Não é uma implementação no sentido de executar código, mas eu realmente gosto do artigo " Como obter uma xícara de café " no InfoQ. Ele descreve o processo de pedir um café na Starbucks como um protocolo RESTful. Isso vai além do artigo introdutório REST típico "tudo é um recurso" e se concentra no HATEOAS. Altamente recomendado.

E a API da Sun Cloud ? Desde a introdução:

A API não pressupõe nenhuma estrutura específica no espaço do URI. O ponto de partida é um URI, fornecido pelo provedor de serviços em nuvem, que identifica a própria nuvem. A representação da nuvem contém URIs para os outros recursos na nuvem e também para operações que podem ser executadas sobre eles (por exemplo, implantar e iniciar máquinas virtuais).

A história de fundo também pode ser útil.

A Netflix possui uma API REST baseada no HATEOAS que inclui links como parte dos recursos.

O RESTfulness da Sun Cloud API não é realmente abordado no quarto ponto de Roy:

Uma API REST não deve definir nomes ou hierarquias de recursos fixos (um acoplamento óbvio de cliente e servidor). Os servidores devem ter liberdade para controlar seu próprio espaço para nome. Em vez disso, permita que os servidores instruam os clientes sobre como criar URIs apropriados, como é feito em formulários HTML e modelos de URI, definindo essas instruções nos tipos de mídia e nas relações de vínculo. [Falha aqui implica que os clientes estão assumindo uma estrutura de recursos devido a informações fora da banda, como um padrão específico de domínio, que é o equivalente orientado a dados ao acoplamento funcional da RPC].

Exemplo 1 Nomes de recursos corrigidos em uma heirachy definida:

Da API da Sun Cloud: "... a representação de um VDC incluirá representações dos Clusters que o habitam, que por sua vez incluem representações das VMs em cada cluster".

Exemplo 2 informações fora da banda, como um padrão específico de domínio:

Você precisa ter o conteúdo da página wiki (informações fora da banda) para saber que o "mecanismo de comunicação de recursos" para o campo de recursos da nuvem "uri" é GET.

Percebi que isso foi perguntado há um tempo atrás, mas tentei demonstrar um fluxo "adequado" da API REST para um exemplo simples. Tentei seguir as regras de Roy para REST - talvez isso ajude: Exemplo de API usando REST