Graph API

sztem gráf, mivel annak alapján modellezi az egész rendszert.

Nekem a fb-tól rémlik elsőként a kifejezés ilyen irányú használata, ott van egy magyarázat is hozzá:

The Graph API is named after the idea of a "social graph" — a representation of the information on Facebook. It's composed of nodes, edges, and fields. Typically you use nodes to get data about a specific object, use edges to get collections of objects on a single object, and use fields to get data about a single object or each object in a collection. Throughout our documentation, we may refer to both a node and edge as an "endpoint". For example, "send a GET request to the User endpoint".

https://developers.facebook.com/docs/graph-api/overview

Persze ettől még simán lehet, hogy oda is máshonnan érkezett..

GraphQL-t is nezd meg, megerted hogy mi ez. Es egy jo texhnologia is. 

A GraphAPI nem egy szabvány.

Microsoft Graph API:

A Microsoft a szolgáltatásait lehet elérni REST-hívásokkal; ezt a szolgáltatást, ezeknek a hívásoknak az együttesének a fantázia neve, hogy "Graph API".

pl. az https://outlook.live.com/ -os  email fiókodat elérheted az IMAP vagy SMTP protokollok helyett REST hívásokkal is, lekérdezheted, vagy kiküldhetsz vele emailt... Létrehozhatsz fájlokat a One Drive-ba... Excel fájlt készíthetsz az www.office.com/ -ra....

Dokumentáció itt: https://docs.microsoft.com/en-us/graph/use-the-api

Facebook:

Úgy tűnik, hogy a Facebook-nak is van hasonló REST-alapú szolgáltatása, amin elérheted a facebook-profilod adataid, utasíthatod szerkeszteni, postolni, aminek véletlenül szintén ugyan az a fantázianeve "Graph API".

Ennek meg itt találtam dokumentációját: https://developers.facebook.com/docs/graph-api

Nincs új a nap alatt...

Szerintem itt a költő arra gondolt, hogy az adatokat nem a REST-es módon, resource+verb kombóval kérjük le, hanem egyfajta speciális nyelven: GraphQL-ben.

Ugye REST-nél két probléma is van:

* kapsz egy csomó dolgot, amire neked lehet, hogy nincs is szükséged, pl. ha téged csak a felhasználó teljes neve érdekel, a többi része nem, egy rakás adat fölöslegesen utazik,

* nem kapsz meg "beágyazott objektumokat", pl. ha neked az összes felhasználó összes telefonhívása kell, akkor először kikéred az összes felhasználót, majd végégtekersz a listán, és kikéred a hozzájuk tartozó összes telefonbeszélgetést. Persze lehet REST endpointot készíteni erre, de minden kombinációra nehéz felkészülni. Arról nem is beszélve, hogy a kliensnek bizonyos mértékig ismernie kell a biznisz domaint, hogy pl. mi mihez van kapcsolva (joinolva) milyen propertyk által.

* bénaság a REST-ben, hogy még a HTT/2-ben is GET/POST/PUT/PATCH/DELETE-tel operálunk, holott lehetne GET/CREATE/... HTTP verbünk is.

* Nem is biztos, hogy mindent lehet resource-ként modelletni, vagy ha igen, akkor is csak nagyon nyakatekert logikával.

GraphQL-ben a kliens dönti el, hogy milyen adatokat szeretne megkapni, és ha kellenek beágyazott objektumok, akkor azokat is megkaphatja ugyanabban a válaszban, természetesen, ezt kóddal meg kell támogatni.

A GraphQL ezen túl mutation-ökkel operál az adatok módosítása céljából, miből van ugye paraméterezett, batch.

Ami még érdekes lehet, GraphQL-ben van subscription, ami nem túl jelentős dolog a mai websocketes világban, de van :-)

Ami REST-hez a Swagger UI (pl. https://petstore.swagger.io/), a GraphQL-hez a GraphiQL (pl. https://graphql.org/swapi-graphql; jobb oldalon ott egy "Docs", azon belül pedig a "Root"-ra kattintva látszik, hogy milyen adatokat lehet queryzni).

query {
    allFilms {
        films {
            id
            title
            planetConnection {
                planets {
                    name
                }
            }
        }
    }
}

Itt a planetConection már beágyazott objektum.