Delphi server android client

Dakle, nisam još definitivno odlučio, ali želim čuti i ovdje mišljenja. Ideja je slijedeća:
Android -> aplikacija za narudžbe u restoranu. Kači se na lokalni wifi, osnovni parametri su u sqlite bazi.
Delphi -> server, prima i obrađuje podatke

Razmišljao sam napraviti jednostavan rest server. Android kod prijave konobara šalje npr
Delphi http server zaprima, provjerava da li postoji konobar 1 i vraća TRUE/FALSE.

Razmišljao sam o Indy http serveru, razmjena podataka JSON.

Molim za iskustva, prijedloge. Ima netko savjet zašto ne/da http server?
Hvala.

Potpis

F

Ako misliš da praviš REST server nema razloga da ne koristiš http server koji najbolje "leži" uz alat - Indy za Delphi, Tomcat za Javu, Kestrel za .Net.
Naravno, uvek možeš i da napraviš svoju implementaciju servera, ali onda moraš sam da procesiraš hedere.

I nije true/false odgovor nego 200 za OK, a neki od statusa 4xx ili 5xx za različite greške.

Ok, hvala djoka. Imaš neko "pametnije" rješenje od REST servera?

Napisao sam true/false jer sam planirao da repsonse bude uvijek neki JSON string, za konkretan primjer npr ili je to loša praksa?

Potpis

F

Pa, nije neki problem da uvek vraćaš neki JSON u response contentu ali nije ni neophodno. Po nekom pravilu, GET treba da vrati JSON, a ako želiš samo da uradiš UPDATE ili INSERT koristiš POST ili PUT metod. Tada se očekuje samo status, a ne i dodatne informacije. Opet, to je stvar tvoje odluke.

Ako misliš sam da uradiš i serverski i klijentski deo, tada budi dosledan samom sebi, a ako želiš da još nekog da uključiš, nemoj da iznenađuješ ljude. Nije problem da se bilo šta isprogramira, samo ne vidim šta time dobijaš.

Ono što je moguća komplikacija je da ne napraviš "overkill" pa da se nepotrebno upetljavaš u REST. Postoje i jaki razlozi zašto REST.bZamisli sledeću situaciju - ne napraviš REST server nego nabudžiš nešto svoje, pa ti onda naručilac posla kaže: ovaj tvoj softver je strava, a da li možeš da sada jelovnik staviš na web sajt restorana?

Jelovnik već držiš u bazi, ali sada moraš da pišeš novi API za web, a drugi za kelnersku aplikaciju.

http://stackoverflow.com/quest...put-operation-return-something

Hvala djoka, od silnog googlanja sada mi je košmaru glavi. REST sam uzeo kao prvi izbor baš iz tog razloga da kasnije budem fleksibilniji.
Jesam dobro shvatio?

Android Client odradi nešto i šalje JSON tipa



i šalje to npr.

(POST)

Delphi Server prima JSON, parsiram ga i zapisujem u bazu.

U obratnom slučaju, kada Android Client zatraži stanje stola 1,

{
"stol":"1"
}

(GET)

Delphi Server šalje JSON na

(GET)

Android Client prima JSON, parsira i prikazuje na ekranu.

Potpis

F

Nije tako.

Klijent šalje nešto tipa:



a server vraca nesto kao


(ne mora ceo URI, moze samo ID 23456)

Ovo je pod pretpostavkom da je ovo prva narudzbenica (PUT) i da se u odgovoru vrati ID 23456. Ako se jos nesto doda onda ides sa POST na localhost:port/appname/v1/narudzba/23456

JSON je UVEK u content delu, u URI ide samo id resursa (a resurs je u ovom slucaju narudzba sa ID: 23456

Da bi dobio sve narudzbine klijent moze da posalje samo


pa da dobije odgovor kao monstruozni JSON


ili da pita samo za specificni id:

Ti pravis serverski deo gde prijavis da neka funkcija reaguje na /appname/v1/narudzba

Funkcija dobija kao argument, recimo varijablu Message
Ti onda mozes da pristupis poljima hedera, recimo sa Message.Header.Content-Type
a samoj JSON poruci kao Message.Content pa da onda parsiras JSON

Ovo nikako. Njemu trebaju biznis odgovori a ne tehnicki odgovori.

Znaci, ako konobar ID 1 ne postoji to nije tehnicki problem nego biznis problem i u tom slucaju svakako treba da vrati HTTP 200 uz odgovarajuci JSON koji ce druga strana da interpretira.

Pa nije tako, hajde da piamo swagger kako treba:
http://petstore.swagger.io/

pogledaj, recimo return kodove za PUT metod za URI /pet


400 Invalid ID supplied
404 Pet not found
405 Validation exception

djoka, puno hvala na trudu, puno je jasnije nego je bilo na prvom pitanju.
Javim se sutra na PM pa možda dogovorimo neku suradnju ako imate vremena.

Potpis

F

Znači ja bi mogao npr. slijedeće?

400 ID konobara ne postoji
401 ID konobara je prijavljen na drugom uređaju
402 ID OK

Ali da li se može definirati na serveru koji kod da vraća za koju grešku? Ili sam zabrazdio sa razmišljanjem?

Potpis

F

Return kodovi su ono sto se definise APIjem. Mozes da vratis bilo sta, ali ako neces da iznenadjujes ljude koji pisu klijenta, vratices 2xx za uspeh, 4xx za gresku.

Znaci ne 402 ID OK, nego 200 ID OK (ili 201 ako je to kreiralo novi slog u bazi, ili 204 ako je content prazan). Uopste ni ne moras da koristis HTTP protokol, mozes da smislis svoj, pa da te programeri koji rade klijentsku aplikaciju mrze kao Nemca

Hahahahahahaha :)
Kužim, pratim logiku 2XX za uspjeh i 4XX za grešku i to je to. Možda sam dosadan sa pitanjima, ali vjerujem da će i drugim kolegama to koristiti :)

Potpis

F

Nemi se taj REST pristup nikako nije uklapao. Kad god sam pravio API, uvek sam se ograđivao od HHTP poruika. Ako se pai izvrši on uvek vrati 200 a u jsonu se nalazi sve što treba pa i statusi grešaka. U praksi se pokazalo kao vrlo korisno, fleksibilno i oslobađajuće od stega HTTP-a.

Nije ništa komplikovano za implementaciju i lako se primenjuje na svim platformama.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Ovo je klasicno silovanje standarda. Ako je negde definisano da je HTTP 404 = Strana ne postoji onda tako treba i da bude a ne da se tehnicke greske koriste umesto biznis gresaka. Kako ce onda da signalizira natrag ako stranica stvarno ne postoji? Da izmisli neki novi kod?

I kako se onda uopste razlikuju biznis poruke od tehnickih poruka?

Po meni ovo je veoma opasno bez obzira sta na nekom sajtu pisalo. HTTP je bio i ostao tehnicki odgovor a biznis odgovore treba lepo upakovati u body (json ili sta god) i teraj...

6.5.4.  404 Not Found



   The 404 (Not Found) status code indicates that the origin server did

   not find a current representation for the target resource or is not

   willing to disclose that one exists.

https://tools.ietf.org/html/rfc7231#section-6.5.4

Prema ovome, ok je upotrebiti ovaj status za nedostajuceg ljubimca.

Opet priča o standardizaciji, naravno da je poželjno pratiti preporuke ali šta ćemo kad npr postoji nekoliko konfliktnih ISO-a, da sedimo danima pred ekranima i plačemo od muke? Poenta je da se reši zadati problem a ne da akademski diskutujemo na ovu temu jer je stara koliko i web 2.0. Turi sve to u lepo formatiran Json, budi dosledan prilikom korišćenja naziva, napravi rečnik i ostatak dokumentacije pa nećeš imati problema ukoliko budeš morao da radiš refactor zbog dublje integracije u drugi API ili zbog promene serverske tehnologije. Bez dokumentovanja svakog bitnog koraka bićeš u problemu pratio standarde ili ne.

Ovo uopste nije teoretisanje vec cista praksa. Naravno da sve moze da se tumaci i ovako i onako ali u citiranom lepo pise da 404 treba da signalizira da resurs sa druge strane ne postoji ili server iz nekog razloga ne zeli da ga da. Dakle, ako pozovem stranicu i server mi kaze 404 to je tehnicki problem a ako mi server da stranicu sa sadrzajem koji mi se ne svidja to je onda biznis problem.

Problem nastaje kada gomila programera koji su totalno odvojeni i operisani od biznisa krenu da primenjuju svoju logiku. Tako se dobijaju ove varijante gde se biznis logika implementira u HTTP odgovore.

Odmah se setim one izreke: "Postoje uvek dva nacina da se nesto uradi: ispravan i laksi.".

Ok, koliko sam shvatio, u header ide kod odgovora 2xx, 4xx a u body ide JSON sa biznis odgovorom?

Potpis

F