Az API csak annyiban különbözik egy normál webapp-tól, hogy más media type-al dolgozik. A hagyományos webapp-ok a html-t adják vissza, amit a böngésző megjelenít, a web api-k meg olyan media type-ban adják vissza a tartalmat, amit a kliens (böngészőben vagy szerver oldalon futó alkalmazás) át tud alakítani a végső html-re, amit a böngésző megjelenít. Van több ilyen media type, pl hal+json, hal+html, json-ld, atom+xml, stb... A lényeg, hogy valami konvenciót kövessen a végeredmény, hogy könnyen lehessen rá eltérő klienseket írni. Így ugyanazt a tartalmat többféleképp lehet megjeleníteni több eltérő klienssel anélkül, hogy különösebben kódot kellene duplikálni... Pl ilyen konvenció, hogy lapozásnál rel=next, rel=previous, rel=first, rel=last linkeket használsz, így kapásból tudja a kliensed, hogy melyik link mire vonatkozik. Lehet curie-ket is használni, hogy az url-ek ne ismétlődjenek olyan sokszor, bár különösebb jelentősége nincs ennek, ha gzip-elve van a válasz...
furcsa
Akkor jól csináltad. :-) Az
Az API csak annyiban különbözik egy normál webapp-tól, hogy más media type-al dolgozik. A hagyományos webapp-ok a html-t adják vissza, amit a böngésző megjelenít, a web api-k meg olyan media type-ban adják vissza a tartalmat, amit a kliens (böngészőben vagy szerver oldalon futó alkalmazás) át tud alakítani a végső html-re, amit a böngésző megjelenít. Van több ilyen media type, pl hal+json, hal+html, json-ld, atom+xml, stb... A lényeg, hogy valami konvenciót kövessen a végeredmény, hogy könnyen lehessen rá eltérő klienseket írni. Így ugyanazt a tartalmat többféleképp lehet megjeleníteni több eltérő klienssel anélkül, hogy különösebben kódot kellene duplikálni... Pl ilyen konvenció, hogy lapozásnál rel=next, rel=previous, rel=first, rel=last linkeket használsz, így kapásból tudja a kliensed, hogy melyik link mire vonatkozik. Lehet curie-ket is használni, hogy az url-ek ne ismétlődjenek olyan sokszor, bár különösebb jelentősége nincs ennek, ha gzip-elve van a válasz...