RESTful 또는 Restbut

리차드슨의 성년 모델을 보십니까?

Leonard Richardson은 2010년 Jin Webber에서 REST in Practice, REST in Practice에 이르기까지 Bíblia가 REST를 사용하기 전에 사용 가능한 API REST 모델을 제안했습니다(sim, publicado a 11 anos!).
⠀
Nesse modelo, são propostos 4 níveis de maturidade:

레벨 0

Definitivamente neste nível não podemos nem chamar de REST.
HTTP 프로토콜은 POX(Plain Old XML)를 기반으로 합니다.

Identificação de recursos – você usa o padrão URI(IRI) para identificar um recurso. Nesse caso, um recurso é um documento da web.

니벨 1

Agrupamos as capacidades in Recursos, Tornando suas APIs um pouco mais organizadas, mas ainda não é uma uma RESTful.

재귀 조작은 meio dessas를 대표하는 것입니다 – você usa o padrão HTTP para descrever a comunicação. 예를 들어, GET은 우리의 재귀 식별 번호에서 회복할 수 있는 이름을 의미합니다. HTTP와 URI를 사용하는 방법에 대해 자세히 알아보세요.

Nível 2 – RESTful

Aqui usamos corretamente os verbos HTTP (당신은 API가 통일 인터페이스를 사용하기 때문에).
Neste ponto, eu já consigo chamar a API de RESTful, apesar de ser difícil encontrar APIs que atingiram completamente os 2 primeiros níveis

Mensagen autodescritivas – 음성 미국 팁 MIME padrão e vocabs RDF(padrão) para tornar as mensagen autodescritivas. Assim, o cliente pode encontrar os dados verificando a semântica e não precisa saber a estrutura de dados específica do aplicativo que o serviço usa.

레벨 3

마지막으로 3번째 버전에서는 HATEOAS와 같은 Hypermedia를 제어합니다.

Hipermídia como mecanismo de estado do aplicativo (também conhecido como HATEOAS) – Você usa hiperlinks e possivelmente modelos de URI para separar o cliente da estrutura URI específica do aplicativo. 예를 들어 IANA 링크와 관련하여 semântica에서 하이퍼링크를 의미하는 Você pode anotar esses, para que o cliente entenda o que eles significam.

{
    "links": {
        "self": "https://sassine.dev/artigos",
        "next": "https://sassine.dev/artigos?page[offset]=1",
        "last": "https://sassine.dev/artigos?page[offset]=40"
    },
    "data": [{
        "type": "artigos",
        "id": "4",
        "attributes": {
            "titulo": "REST(ful) ou REST(but)"
        },
        "relationships": {
            "autor": {
                "links": {
                    "self": "https://sassine.dev/articles/4/author",
                    "related": "https://sassine.dev/articles/4/author"
                }
            },
            "comentarios": {
                "links": {
                    "self": "https://sassine.dev/articles/4/comments",
                    "related": "https://sassine.dev/articles/4/comments"
                }
            }
        },
        "links": {
            "self": "https://sassine.dev/artigos/4"
        }
    }]
}

Apenas analisando esta única resposta, um cliente sabe:

O que foi Consultado( **기사 **예제)

Como está estruturado artigos objetos (id, titulo, autor, comentarios)

Como recuperar objetos relacionados (ou seja autor, a lista de comentarios)

Que há mais artigos(com 10 base no comprimento da resposta atual e link de paginação)

Agora que já conhece um pouco do modelo, onde sua API está?
Podemos chama-la de RESTful ou está mais para RESTbut?