Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
- Hidvégi Gábor:
Egyszerű hibakeresés - erenon:
PHP osztályok egységtesztelése II 
Hodicska Gergely:
DAO - Adatbáziskezelés picit másképp
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
Sütemény
Köszi! Én nem ragaszkodom semmihez. :)
Igazság szerint inkább csak érdeklődök, hogy a leírtakat jól értem-e, vagy sem?
A konkrét problémámra a megoldás meg valószínűleg az lesz, hogy egyszerűen nem nevezem RESTful-nak és akkor nincs ellentmondás. :)
úgy értsd, hogy
tehát első kérés mondjuk egy auth, ez visszaad vmi azonosítót, amit a többi kérés elküld (session cookie tulajdonképpen)
és nem lehet olyan kérés, hogy cancelLastRequest pl.
Hol a határ?
Értem az idézett mondatot, de nem tudom, hogy hol a határ.
Adott egy egyszerű lekérés, arra egy egyszerű válasz.
Jön egy utasítás, hogy álljunk át hibakereső módba. (ez egy másik típusú http kérés, és ezt nem tudom, hogy ez mennyire RESTful)
Majd ismét meghívjuk az első lekérést és már egy teljesen más, részletesebb válasz érkezik.
Ekkor nem igaz az a feltétel, hogy az előzmények nem voltak hatással az aktuális lekérésre. Illetve a szerveren lévő klienshez tartozó információ miatt jött az létre, hogy ugyanarra a lekérésre más válasz születik.
De lehetséges, hogy ezt most csak én kombinálom túl.
kliens oldalon?
hogy nyersz-e ezzel valamit vagy sem? nem tudom, de Poetro biztos tudja :)
Re: kliens oldalon?
Egy megoldás lenne, hogy extra header-eket csinálunk. (bár lehet, hogy nem baj, ha nem hívom REST api-nak és akkor nincs gondom:)
Az zavar, hogy sehol nem láttam azt leírva, hogy REST = nem használhatsz Session-t. De ha nem arra használom a session-t, hogy idővel megváltozzon az értéke, akkor mire használnám? Tehát nem tudok elképzelni olyan valós példát, ahol használok Session-t, de mégsem sérül az a feltétel, hogy az előző lekérés befolyással van a következő lekérésre.
elvileg az url nem lehet
Ez nem igaz! A protokoll (RFC2616) nem tartalmaz limitet
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Az implementációkra azonban ez nem feltétlenül igaz, de 255 karakter nem okozhat problémát egyik böngészőnek sem, az IE is csak 2000 karakter körüli url-hossznál hal le.
A 255 karakteres limit csak egy ajánlás, és a hosztnévre vonatkozik (ez csak a DNS miatti limitáció). (RFC3986)
Re: url hossz
Nekem továbbra is nagyon nem tetszik az, hogy REST = ne használj Session-t, igazság szerint titkon abban reménykedem, hogy valaki majd jön és jól megmagyarázza, hogy miért szabad mégiscsak használni. :)
LUSTA
Olvasgatom a wiki linket:
Nem választottam...
Adott egy webes szolgáltatás, amelyről először Android telefonok kértek le infókat. Elkészült a rendszer úgy-ahogy. Majd amikor az IOS-s oldalt készítették, akkor rákérdeztek, hogy akkor egy REST api-ról beszélünk-e? Ekkor én még nem tudtam, hogy arról beszélünk-e. :) Vagyis még most sem tudom, de ekkor kezdtem el gondolkodni, hogy milyen frankó lenne, ha tényleg erről beszélnénk. :)
Várhatóan felmerül majd a harmadik mobilplatform, és nem szeretnék teljesen hülyén állni, ha majd a harmadik csapat is rákérdez erre. Emiatt a topic. :)
(annyira nem ragaszkodom én a "szabványhoz", hogy emiatt a felépítést átírjuk, csupán érdeklődök)
A REST arról szól, hogy az
Milyen jellegű dologra kell neked a session?
Felhasználók
Ez alatt mit értesz?
A legegyszerűbb példa, amikor
De itt REST api-ról van szó,
De egyébként akárhányszor frissíted az oldalt, mindig az lesz, hogy "Bejelentkezve X. Y. néven" :-).
Autentikáció&autorizáció és egyebek a REST koncepciójában is benne vannak természetesen (pl. OAuth protokollon keresztül), nem mondanak ellent a korábban említett állításoknak.
Akkor valószínűleg
A kliens kezelhet
Kérnék egy kis pontosítást! :)
Mit jelent, hogy a kliens kezelhet munkamenetet, de a szerver nem tárolhat munkamenetet? Mit kezel a kliens, ha a szerver nem tárol hozzá semmit? Ha a kliens átadja a session_id, akkor azért adja át a szervernek, hogy az annak megfelelő választ adjon. Azaz a szervernek csak kell tárolnia valamit.
The client–server
Kiemelés tőlem. A lényeg, hogy minden kérés egy atomi tranzakció, a kérések nem függenek össze, a szerver állapota mindig konzisztens kettő közt. A legjobb ellenpélda a többoldalas űrlap.
Szerintem egyszerűbb