The JSON API Spec

Поделиться
HTML-код
  • Опубликовано: 2 окт 2024
  • Most projects these days expose or consume some kind of JSON based API, usually working in a RESTful manner. So while the combination of JSON as a data transport format and REST as a means of exposing actions on data seems fairly widely adopted, all these APIs are slightly different. Trivial decisions about implementation details with respect to the exact JSON structure, naming of REST endpoints etc. are repeated over and over with every team coming to different conclusions, resulting in slightly different APIs. Not only does that result in centuries of man-years being wasted in bikeshedding discussions but also is a massive impediment for code reuse across projects. The JSON API spec is all about making these trivial decisions once so you don’t have to. This talk introduces the spec, explains what it defines and why it does and points out how everyone profits from adopting it.

Комментарии • 13

  • @theilluminatimember8896
    @theilluminatimember8896 2 года назад +5

    I really liked this video, very useful to get behind the thought process on how it's used and why things are how they are.

  • @ruixue6955
    @ruixue6955 5 лет назад +18

    10:31 the spec
    11:57 resource object

  • @rubyaumaroc5576
    @rubyaumaroc5576 2 года назад +1

    Thanks for the talk, by the way swagger works with JSON:API

  •  Год назад

    I view common connect backend with frontend. But i many question for common JsonAPI
    + do it support wcf?.
    + do it support logic n-tier
    + do it support upload file
    + do it support extension to integration other converts json.
    + do it support perfomance when scale multi services
    Thanks

  • @figase6231
    @figase6231 4 года назад +5

    It really feels that this protocol is trying to cover all possible scenarios what results in a huge overhead and makes it too chatty. I really believe in simplicity, e.g. articles should be an array of objects with attributes. Relations should be nested. The idea of "included" is neat though as it provides a sort of storage right in a response. Generalization is not always for the best, simplicity is.

    • @delaneygillilan
      @delaneygillilan 3 года назад +1

      then you might as well have GraphQL, the flatness is great for client side caching and partials & etags, something GQL doesn't do

  • @CrzyGazara
    @CrzyGazara 5 лет назад +6

    The Content is very good but i had hard time following you up it seems that you are getting your wording on the spot while very good but it ruins our thought train , thanks again for this material.

  • @bob-pk2ly
    @bob-pk2ly 2 года назад +1

    Appreciate the information !

  • @praadiiit
    @praadiiit 3 года назад

    I've tried it and it seems hard to me to make a relationship url fot every using Laravel

  • @zakariachahboun
    @zakariachahboun 4 года назад +1

    2:35 Where is Linux 🙄

  • @einfacherkerl3279
    @einfacherkerl3279 5 лет назад +12

    6:00 i think he needs water not json.

    • @neon13x
      @neon13x 3 года назад +13

      He is stuttering dude, don't criticise him for speaking like that. I also stutter and I know how hard it is for him to give this talk.