ugrás a tartalomhoz

Hypermedia APIs

inf · 2013. Okt. 8. (K), 19.10
Hogyan kell helyesen REST API-t tervezni
 ■
1

Szép. Még fájdalmasabbá teszi

Joó Ádám · 2013. Okt. 8. (K), 19.13
Szép. Még fájdalmasabbá teszi a tényt, hogy a HTML5 még mindig csak GET és POST használatát engedélyezi.
2

Szubjektív kontra

Arnold Layne · 2013. Okt. 8. (K), 21.20
Ennél — szerintem — még fájdalmasabbá teszi az is, hogy webalkalmazások kliens oldalához okvetlenül kell a HTML és a CSS is. Szerintem bőven elég lenne alkalmazásokhoz csak a JS. Máshol elég egyféle nyelv hozzá, ide minek több? De ez az én szubjektív véleményem.
3

A lehetőség adott, a DOM és

MadBence · 2013. Okt. 8. (K), 21.36
A lehetőség adott, a DOM és az elemek megjelenése is közvetlenül manipulálható JS-ből.
4

Csak JS

Poetro · 2013. Okt. 8. (K), 21.42
DOM stuktúrát tudsz létrehozni JS-ből, ahogy CSS stíluslapokat is. Szóval minden lehetőség adott ehhez, és én például a mindennapi munka során ki is használom ezeket.
5

SEO

Pepita · 2013. Okt. 8. (K), 22.03
És mindebből mit látnak a keresők?
Szerk.: jól tudom, hogy a barátod - nem az enyém :) - elég jól "tanulja" a js-t, jQuery-t?
Persze nagyban függ a szervertől jövő adatszerkezettől.
Ebben a témában (is) nagyon érdekelne egy cikk...
(Úgy látszik mostanában nagyon "cikkéhes" lettem.)
6

keresők, alkalmazás, tartalom

Arnold Layne · 2013. Okt. 8. (K), 22.57
És mindebből mit látnak a keresők?

Szerintem egy keresőnek nem sok köze kell legyen az alkalmazáshoz, sokkal inkább a tartalomhoz. Az, hogy ez a kettő ennyire össze van nőve és ebből próbálunk várat építeni… ezen valahogy mind a mai napig nem sikerült túltennem magamat. :(
10

Az a szép a hypermedia

inf · 2013. Okt. 9. (Sze), 18.13
Az a szép a hypermedia api-ban, hogy maga az adatszolgáltató réteg teljesen ugyanúgy kereshető html vagy xhtml esetében, mintha stíluslapokkal, meg minden szeméttel teleszórt weboldal lenne...
7

Nem érdekes

Poetro · 2013. Okt. 8. (K), 23.49
Nem igazán érdekes, hogy mit látnak abból a keresők, amit jelenleg csinálok, mivel semmit sem láthatnak belőle. A tartalom csak az alkalmazás felhasználójára tartozik.
Mit látnak a keresők a te Yahoo!, Gmail vagy Outlook.com leveleződből a keresők? (Ha szerencsénk van nem sokat.)

Böngésző alapú alkalmazásokat nem feltétlen a keresőknek készítjük, hanem inkább a felhasználóknak. Ha a felhasználó kényelmesen tudja használni azt a saját eszközén, akkor mindenki nyert, lényegtelen a mögötte levő technológia.
8

Papírhúszas

Pepita · 2013. Okt. 9. (Sze), 05.48
Pl. a webshop termékeit kell látnia a keresőnek, de a termék (tartalom) létrehozásához szükséges alkalmazást korántsem... (Meg van néhány eset, amikor semmit sem.) Itt vettem nagyon egy kalap alá a dolgokat. Köszi, így tiszta.
11

Nézd meg kicsit jobban a

inf · 2013. Okt. 9. (Sze), 18.16
Nézd meg kicsit jobban a cikket, ha hypermedia api-t használsz, akkor gyakorlatilag mindent látnak a keresők az adat részből, amit publikusan kiszolgálsz. Annyi a különbség, hogy csinálhatsz egy teljesen külön csilli-villi klienst, amit az emberi felhasználóknak adsz át, a botoknak, meg a hypermedia api által küldött adatokat szolgálod ki. Ha a content type html vagy xhtml, akkor tudják értelmezni, követni a linkeket, meg minden mást, amit egy sima weboldalon lehet.
9

+1, szerintem is csak egy

inf · 2013. Okt. 9. (Sze), 18.11
+1, szerintem is csak egy értelmes js api kellene a böngészőkbe, amivel össze lehet szórni a felhasználói felületet... Most végülis ugyanilyeneket tolunk elég sokan, csak mégse natívban, hanem keretrendszerrel.
12

És ezzel mi a probléma? Mi a

Hidvégi Gábor · 2013. Okt. 10. (Cs), 18.59
És ezzel mi a probléma? Mi a különbség a kettő között:
DELETE /eroforras=26
és
GET /action=delete&eroforras=26
13

Inkább meg sem láttam, hogy

Joó Ádám · 2013. Okt. 10. (Cs), 21.12
Inkább meg sem láttam, hogy ilyet írtál, és úgy veszem, hogy a második POST. Csak annyi vele a probléma, hogy a REST API-k ki szokták használni az összes HTTP metódust – miért ne tennék, ha egyszer részei a protokollnak? –, ami aszinkron kérések esetén nem okoz gondot. De amint JavaScript helyett egy sima HTML klienst tennél elé, ahogy azt az előadás bemutatja, nem tudod elküldeni a PUT és DELETE kéréseid.
14

És a kérdésre mi a válaszod?

Hidvégi Gábor · 2013. Okt. 11. (P), 07.04
És a kérdésre mi a válaszod?
15

A különbség természetesen

MadBence · 2013. Okt. 11. (P), 10.48
A különbség természetesen csak annyi, ami a két string között van. Mindkettőt azonosan lehet feldolgozni, csak szemantikában van különbség.

Ennyi erővel lehetne

GET /

Majd a lekérdezés törzsében

<actions>
  <action>
    <name>delete</name>
    <params>
      <param>
        <name>id</name>
        <value>26</value>
      </param>
    </params>
  </action>
</actions>


Vagy hasonló rondaság. Ez is ugyanolyan jelentéssel bír, csak az adatok megjelenítés radikálisan más (rest esetén radikálisan egyszerű, soap vagy hasonló szörnyeteg esetén meg radikálisan bonyolult).
16

Csak arra szerettem volna

Hidvégi Gábor · 2013. Okt. 11. (P), 10.58
Csak arra szerettem volna rámutatni, hogy az új kéréstípusok bevezetésével (látszólag) semmit sem nyernénk, így teljesen felesleges erre időt pazarolni. A HTML meg a REST is one time write only, azaz egyszer megírod, és utána működik, az már a perverzió kategória, ha utána bárki is a forrást nézegeti kedvtelésből, és szerveroldalon is tökéletesen mindegy, hogy melyik formában kapja a bejövő kérést. Vannak ennél fontosabb problémák.
17

Azért annyira nem mindegy. A

MadBence · 2013. Okt. 11. (P), 11.28
Azért annyira nem mindegy. A GET kérés tipikusan olyan, hogy nem változtat állapotot. Ezért a crawlerek is így másznak végig az oldalakon. Meglehetősen kellemetlen, amikor egy törlő linkekkel teli oldalt "indexel" be előzékenyen :-).
18

Ezért szoktunk törlés előtt

Hidvégi Gábor · 2013. Okt. 11. (P), 11.36
Ezért szoktunk törlés előtt kérdést feltenni vagy a linkbe tenni egy rel="nofollow" attribútumot.
19

A kérdés csak egy

Joó Ádám · 2013. Okt. 11. (P), 12.03
A kérdés csak egy kattintással később jeleníti meg ugyanazt az URL-t. A nofollow pedig nem ekvivalens, mert például a böngésző címkiegészítésére, előtöltésére nincs hatással. Remélem tudod, hogy most éppen konkrét gyakorlati veszélyt hordozó megoldást hirdetsz nyilvánosan, azért, mert mostanában valahogy már a szemantikus XML-en kívül minden mást feleslegesnek tartasz. Nem biztos, hogy ez szerencsés.
20

Prioritások

Hidvégi Gábor · 2013. Okt. 11. (P), 12.23
Az interneten fenn van minden, a technológiai korlátok miatt mégis csak egy elhanyagolható töredékét tudjuk megtalálni a minket érintő információknak. Amíg ezt a problémát meg nem oldjuk, minden csak az időt veszi el attól, hogy megoldjuk; mindenki úgy csinál, mintha időmilliomos lenne, de egyszerűen huszonkét év alatt képtelenek voltunk túllépni ezen a feladaton, egy helyben toporgunk.

Van GET-ünk, van POST-unk, ezzel a kettővel le tudjuk fedni az összes kérést (POST esetében már nincs előtöltés, ti nyertetek, a GET erre nem a legtökéletesebb, bár biztos vagyok benne, hogy megoldható ezzel is), akkor ráérünk új neveket keresgélni a kérések típusainak, ha nem lesz ennél fontosabb. Abból kell főzni, ami van.
21

Én azt nem értem, mi a bajod

Joó Ádám · 2013. Okt. 11. (P), 13.00
Én azt nem értem, mi a bajod azzal, hogy a már meglévő, szabványos technológiát használjuk. Nem kell keresgélni, tizenöt éve kész, erőráfordítást nem igényel.
22

Nem értem, itt mire gondolsz.

Hidvégi Gábor · 2013. Okt. 11. (P), 13.11
Nem értem, itt mire gondolsz. A DELETE-re és társaira?
23

Igen.

Joó Ádám · 2013. Okt. 11. (P), 13.11
Igen.
24

Még fájdalmasabbá teszi a

Hidvégi Gábor · 2013. Okt. 11. (P), 13.23
Még fájdalmasabbá teszi a tényt, hogy a HTML5 még mindig csak GET és POST használatát engedélyezi.
Nem nekem van ezzel bajom, hanem neked : ) Nekem aztán tök mindegy, ki mit használ, én csak azt kérdőjeleztem meg, hogy van-e értelme tovább finomítani a kérések típusát.

Ez pont ugyanaz a probléma, mint a html-ben a role attribútum, amely értékeinek egy részét átvették új tag-ek formájában (header, footer, main és társaik), de nem mindet. A role attribútum jóval rugalmasabb, mint új tag-eket bevezetni (pl. a main elem csak később került be az ajánlásba), ugyanez igaz egy POST + pl. action nevű változó kombinációjára is.
25

A HTTP metódusok teljesen

Joó Ádám · 2013. Okt. 11. (P), 13.30
A HTTP metódusok teljesen rugalmasak, olyat használsz, amilyet akarsz, pont mint a role attribútum esetében. A HTML az, ami önkényesen csak a GET és POST metódust engedi szerepeltetni az űrlap method attribútumában.
26

Ez még nem is lenne baj,

Hidvégi Gábor · 2013. Okt. 11. (P), 14.11
Ez még nem is lenne baj, inkább az, kipróbáltam, hogy ha más metódust adsz meg egy form-nak, akkor a böngészők automatikusan GET-ként értelmezik. Egyébként pedig erre csak egy klasszikust tudnék idézni: "A modern böngészők miatt nem fejlődik a web" : ) Hisz ők csinálják a szabványokat is (WHATWG).
27

Én is erre gondoltam. Az,

Joó Ádám · 2013. Okt. 11. (P), 14.41
Én is erre gondoltam. Az, hogy esetleg nem validál, már nem ráz meg, de a gyakorlatban sem engedik használni.
28

Gondolom, nem szeretnének

tgr · 2013. Okt. 11. (P), 21.52
Gondolom, nem szeretnének ipari mennyiségű biztonsági rést nyitni legacy webservice-ekben.
29

Mert ha valaki ki akar

Joó Ádám · 2013. Okt. 11. (P), 22.11
Mert ha valaki ki akar használni egy biztonsági rést, akkor HTML űrlapból fogja küldeni a kéréseket?
30

Igen, CSRF-fel.

tgr · 2013. Okt. 11. (P), 22.27
Igen, CSRF-fel.
31

Hogy nézne ki egy ilyen

Joó Ádám · 2013. Okt. 11. (P), 22.41
Hogy nézne ki egy ilyen támadás? Milyen legacy webservice lenne ez?
32

Bármi, ami sütiket használ,

tgr · 2013. Okt. 12. (Szo), 11.11
Bármi, ami sütiket használ, és eddig abból indult ki, hogy nem lehet PUT/DELETE CSRF támadást csinálni. Vö. pl. ezzel vagy ezzel.