Le Guide API ReST | Marmicode
  • Le Guide API ReST par Marmicode
  • API ReST
    • L'Ecosystème Moderne
    • Le Besoin
    • Re.S.T. : REpresentational State Transfer
    • Les 5 règles et ½ de l’API ReST
    • Le Modèle de Maturité de Richardson
    • H.A.T.E.O.A.S. & Resource Linking
    • Avis Subjectif sur H.A.T.E.O.A.S. et le Semantic Web
    • ReST over HTTP
    • HTTP & CRUD
    • ReSTful donc Stateless
    • Pragmatisme, Idéologie et ReSTafarians
  • Conventions & Bonnes Pratiques
    • Nommage
    • Base URL
    • Media Type
    • Versioning
    • Propriété “id”
    • Polymorphisme
    • Datetime
    • Ressource d'Association
    • Pourquoi Appliquer ces Bonnes Pratiques
    • Zalando ReSTful API Guidelines
  • Les Outils
    • Swagger
    • OpenAPI Visual Editors
    • IDE Plugins
    • Postman
    • Insomnia
    • Fake & Sandbox
    • JSON Generator
    • Pact
  • Sécurité des APIs ReST
    • OWASP Top 10
    • Authentification et Session Management
    • Autorisation et Gestion des Permissions
    • Validation, Canonicalization, Escaping & Sanitization
    • Cookies are EVIL
    • C.O.R.S.
    • C.S.R.F.
    • C.S.R.F. & Media Type
    • C.S.R.F. Mitigation
    • C.S.R.F. & "Resource Linking"
    • J.O.S.E.
      • J.W.K.
      • J.W.S.
      • J.W.E.
    • J.W.T.
      • Description et Fonctionnement de JWT
      • Usages et Avantages
      • Utilisation de JWT pour l’Authentification
      • JWT, Authentification, Sessions et Risques Sécurité
      • Recommandations JWT
    • OAuth 2
      • OAuth 2 Roles
      • OAuth 2 Abstract Flow
      • OAuth 2 Authorization Code Flow
      • OAuth 2 Implicit Flow
      • OAuth 2 Resource Owner Password Credentials Flow
      • OAuth 2 Client Credentials
      • OAuth 2 Registration
      • OAuth 2 Risques & Recommandations
      • OAuth 2 Substitution Attack
    • OpenID Connect
      • Terminologie
      • Quoi de Neuf ?
      • OpenID Connect Flows
      • Que Faire ?
  • Autres Spécifications
    • JSON API
    • H.A.L.
    • JSON LD
    • Les Autres Initiatives
    • So What?
  • Quelques Liens & Ressources
  • Stay Tuned
    • 📝Blog
    • 🐦Twitter
    • 📬Newsletter
Propulsé par GitBook
Sur cette page
  • Cool 👍
  • Pas cool 👎
  1. Autres Spécifications

JSON API

PrécédentAutres SpécificationsSuivantH.A.L.

Dernière mise à jour il y a 6 ans

  • Créé par le co-fondateur de , une entreprise de conseil (en jsonapi ?).

  • C’est une spécification et non un standard.

{
    "links": {
        "self": "http://example.com/articles",
        "next": "http://example.com/articles?page[offset]=2",
        "last": "http://example.com/articles?page[offset]=10"
    },
    "data": [{
        "type": "articles",
        "id": "1",
        "attributes": {
            "title": "JSON API paints my bikeshed!"
        },
        "relationships": {
            "author": {
                "links": {
                    "self": "http://example.com/articles/1/relationships/author",
                    "related": "http://example.com/articles/1/author"
                },
                "data": {"type": "people", "id": "9"}
            },
            "comments": {
                "links": {
                    "self": "http://example.com/articles/1/relationships/comments",
                    "related": "http://example.com/articles/1/comments"
                },
                "data": [
                    {"type": "comments", "id": "5"},
                    {"type": "comments", "id": "12"}
                ]
            }
        },
        "links": {
            "self": "http://example.com/articles/1"
        }
    }],
    "included": [{
        "type": "people",
        "id": "9",
        "attributes": {
            "first-name": "Dan",
            "last-name": "Gebhardt",
            "twitter": "dgeb"
        },
        "links": {
            "self": "http://example.com/people/9"
        }
    }, {
        "type": "comments",
        "id": "5",
        "attributes": {
            "body": "First!"
        },
        "relationships": {
            "author": {
                "data": {"type": "people", "id": "2"}
            }
        },
        "links": {
            "self": "http://example.com/comments/5"
        }
    }, {
        "type": "comments",
        "id": "12",
        "attributes": {
            "body": "I like XML better"
        },
        "relationships": {
            "author": {
                "data": {"type": "people", "id": "9"}
            }
        },
        "links": {
            "self": "http://example.com/comments/12"
        }
    }]
}

Cool 👍

  • Définition d’un format strict mais extensible.

  • Standardisation des paramètres de sorting, filtering et de pagination (l’implémentation reste libre pour la pagination).

  • L’idée du resource linking avec des relationships est intéressante.

Pas cool 👎

  • Risque de collision entre les fields présents dans attributes et relationships.

  • Pas de différence entre un lien vers une instance ou une collection.

  • Les one-to-one relationships sont ambigües et ne respectent pas la convention : /resources/:resourceId/sub-resources/:subResourceId

  • Attention, les exemples utilisés dans la spec adoptent des conventions inhabituelles et ne sont pas imposés par la spec.

    • L’utilisation des fields en kebab-case n’est pas dans le standard.

    • La propriété type n’est pas forcément au pluriel.

  • L’idée des bulk operations sur les relationships est très intéressante mais malheureusement pas appliquée aux ressources.

  • De nombreuses implémentations mais la plupart ne sont plus maintenues depuis des mois voire des années.

http://jsonapi.org/
http://www.tilde.io