JSON schema validation

Sa stim exact cu ce input lucram:

3 Likes

mi se pare mai util swagger, are un pachet de beneficii mai mare, incluzand generare automata de api docs

strict legat de validare, si guzzle avea acum vreo 2 ani built-in, m-a salvat din multe belele, acum nu stiu pt ca nu l-am mai folosit

Luand un exemplu de schema “advanced”:

{
    "id": "http://some.site.somewhere/entry-schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",
    "description": "schema for an fstab entry",
    "type": "object",
    "required": [ "storage" ],
    "properties": {
        "storage": {
            "type": "object",
            "oneOf": [
                { "$ref": "#/definitions/diskDevice" },
                { "$ref": "#/definitions/diskUUID" },
                { "$ref": "#/definitions/nfs" },
                { "$ref": "#/definitions/tmpfs" }
            ]
        }
    },
    "definitions": {
        "diskDevice": {},
        "diskUUID": {},
        "nfs": {},
        "tmpfs": {}
    }
}

via http://json-schema.org/example2.html

Nu cumva intram too much in business logic cu oneOf, required, definitions, sub-schemas etc. ?

An API/JSON endpoint is just a representation - internally este inca o abstractie peste our models/repos/services et al. de asta si folosim - serializers, presenters, representers, what-ever-you-what-to-call-that-layer

Iar in acel nivel intra si validarile specifice + shared - deci de ce as mai adauga inca un layer - care:

  • nu este flexibil
  • it’s basically a DSL with its own rules
  • inca nu este un standard ci aparent doar a draft?

personal note: generating API docs without manual editing or doing that in the code (via comments and stuff) is one of the easiest ways to royally fuck up and piss off every consumer of your API.

2 Likes

Ca o curiozitate, acel $ref este legat de $ din php? Sau doar vrei sa separi cazurile exceptionale de restul definitiei? (Am presentimentul ca este unul din momentele alea cand nu vad padurea de copaci sau invers…)

$ref e ca un pointer - gasesti definitia pentru schema in alt loc. Altfel, daca ai avea 3 UUID-uri intr-o definitie, ar trebui sa repeti de 3 ori definitia.


JSON-schema are $ceva valoare. E folositoare pentru genul de om care vrea sa scrie la intarea intr-un API o bucata de validare cat mai completa. Dar cumva nu ajunge pentru 100% din cazuri, deoarece descrie doar structura datelor, si putine valori pentru forma primitivelor. Dar nu ai putea exprima ceva de genul: X este un set de intregi, iar Y continue un subset din acestia.

Eu privesc treaba asta ca pe un prim punct de strong typed. Primesc un input json cu key-uri ale caror tipuri le cunosc, le pot folosi ca atare, si nu voi face mereu verificari paranoice pentru a fi sigur de datele cu care lucrez. Evident, nu-i ceva exhaustiv.

Asta inseamna ca limbajul din spate este weakly typed: JS/PHP? Presupun ca it makes sense there - daca la asta te-ai referit.

Desigur. Articolul din link exemplifica situatia in PHP.

Pentru alte limbaje (GO, Java etc) ii o chestiune default sa ai o structura bine definita (schema in cazul articolului de fata) in care se transpune un input text cum ar fi json.

In caz ca nu ai observat am dus discutia un pic mai departe si anume JSON schema everywhere, de altfel am si adaugat un extra tag in thread (api). Pentru ca este un subiect chiar interesant. :slight_smile:

Da, insa chiar si pt. PHP acea structura poate fi inlocuita de acel extra layer - de care, oricum este nevoie, unless the API is simple => aici era argumentul meu.

JSON-schema merge putin mai mult totusi decat ce-ti ofera un typesystem clasic. Poti sa faci assert-uri despre cate elemente are o lista, despre formatul unui string, range-ul unui intreg etc. Fiind JSON, e usor de preluat si folosit in diverse limbaje dintr-un code-base.

*with a specific set of rules added on top and not a standard yet

1 Like

Standardul, atat cat e el, specifica ca o schema trebuie sa fie JSON. Pe de alta parte, ar putea sa fie si YAML sau xml, atata timp cat tool-urile care lucreaza cu ea stiu de asta.

1 Like

Categoric. Eu am mentionat partea de “prim punct de strong typed” doar dintr-o chestiune subiectiva, ca simt tot mai mult nevoia de a lucra cu tipuri bine definite. De exemplu, la PHP 7 am folosit din start beneficiul strict types.

Yup, de asta m-am mutat pe TypeScript, de la Python, ca “limbaj de hackuit”. Ideal, type-systemul ar putea sa exprime toate constrangerile pe care le vrem, de la un input. Nu prea exista astfel de sisteme din nefericire / si niciunde intr-un limbaj de productie.

Pai, solutii exista, cum ii chiar articolul de fata. Solutia prezentata nu rezolva toate problemele lumii, dar ofera suport pentru o chestiune de baza si cu impact printr-un layer subtire.

Nu inteleg totusi ceva - partea cu prim punct de strong typed nu cumva ai vrut sa zici static? Pentru ca odata ce un string trece prin JSON schema validation si ajunge in PHP tot poti face:

// validation passes at this point
// $params['type'] = 'Post';
$some_value = $params['type'] + 2; 
// => Post2 i.e. weak typing still at hand

Da, in cazul PHP oricum poti nenoroci o variabila, oricat ai verifica-o inainte. Strong typed l-am folosit pentru a defini “tipuri de date cunoscute”. Cand vorbim de PHP < 7 strong si static is niste termeni din alte povesti (nu stiu daca am folosit cea mai buna descriere).

1 Like