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?

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.

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:




_{[Ovu poruku je menjao djoka_l dana 06.04.2017. u 01:36 GMT+1]}

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.

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?

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 :)

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.

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?

Vidi, ako gledas sa tehnicke strane ne postoji ovde tacan i pogresan odgovor. Mozes da radis i na jedan i na drugi nacin.

Moj ti je predlog da HTTP odgovor treba da signalizira da li je poziv uspeo ili nije (200 OK, 404 Not found etc.) a ako je poziv uspeo onda treba da u JSON odgovoru (ili koju god metodu za serijalizaciju da koristis) kazes "Ok, primio sam porudzbinu" ili "Ne, nisam primio porudzbinu jer...".

Iskustva su različita i odlično je to što se razmenjuju. Moje iskustvo je da su preporuke oko implementacije REST-a priča koja pada u vodu kada se pročešljaju 3rd party Api-s. Onda svakako sledi čitanje dokumentacije jer to što preporuka (koja od?) govori jedno ne znači da je ispravno implementirana. Postoji brdo rešenja koja koriste možda 20% predloženog standarda a da pritom nisu u celosti ispratila semantiku. Tako vrlo lako dolazi do "Ohh... " momenata pa se vraćamo na početak. Ukoliko se razvija REST aplikacija za širi krug svakako podržavam detaljisanje, međutim stekao sam utisak da bi zahteve OP-a brže rešio RESTful sistem, pogotovo zato što mi se čini da je još uvek u procesu analize sistema.

U heder ide 4xx, 200 je samo za očekivan rezultat.

Po meni je najbolje resenje web klijent (ako treba lako mozes iskompajlirati Android/iOS) i u startu gadjas sve platforme.
Za klijentski deo pogledaj EWB ili SMS/uniGui, sve je to Pascal/Delphi tako da si vec na domacem terenu.
Za serverski deo uzmi opet Delphi i mORMot framework imas ultra brzi TCP/IP server (REST ili kako hoces), sve sto se tice JSONa, sve baze podrzane i brdo drugih stvari. Trebace ti par meseci da shvatis kako ide ali ce se isplatiti na duge staze.

Ne vidim razlog sto se ovde ne koristi najjednostavnija socket komunikacija, sa "kucno pravljenim" apijem, regexom i slicno?

hvala savkic, gledao sam mormot ali kao šta kažeš, tu mi treba par mjeseci da sve pohvatam. A ja sam računao ovo složit u 2 mjeseca i android i server dio, tako da ovu sezonu već bude na testiranju. Delphi mi nije problem, sa javom nisam na ti ali to ču odraditi. Zato tražim najbezbolnije rješenje a da opet nije izbuđeno, tj. da kasnije mogu to elegantno nadograđivati. JSON mi je izgledao kao najelegantiji način za prijenos podataka, pa sam samim time uzeo REST kao prvi izbor. Java ima ok library za rest i json manipulaciju, delphi (7) ima indy, json nativno ne podržava ali bi ili sam napravio parser ili iskoristio neki od dostupnih, za ono šta meni treba su sasvim dovoljni.
Uglavnom, izgubljen sam u prostoru i vremenu i teško mi je odlučiti.

Sada gledam unigui, ne izgleda to loše. Imaš iskustva kako to radi na mobilnim telefonima?

Ja vidim, mada sam predložio da zaobiđe ceo REST i radi kako mu je lakše. Pitanje je šta misli u budućnosti da radi sa tom aplikacijom.

Šta ako mu sledeći zahtev bude da stavi jelovnik na web sajt restorana?
Šta ako naručilac posla traži da se obezbedi on-line naručivanje hrane?
Šta ako na kraju naručilac posla zahteva da mu se restoran pojavi na donesi.com? Tada će MORATI da uradi REST API kako je definisao Kupindo.

Ako će aplikacija da se završi samo na jednom restoranu, sa specijalizovnom aplikaciom samo za kelnere, onda može da uradi onako kako mu je naklakše. Slupa neki php sajt, ne mora ni da koristi framework i to će da radi.

Aplikacija će raditi u više restorana, ali ne mislim raditi za svakog posebno. Desktop aplikacija mi je jako skalabilna i do sada nisam imao potrebe prilagođavati nekom posebno. Zato želim i taj dio naručivanja odraditi odmah u startu kako treba da izbjegnem kasnije glavobolje. Kako djoka kaže, lako moguće (a bilo je već upita) da se u budućnosti pojavi potreba odraditi npr. da gosti sami mogu naručiti hranu. Tu bi bio u velikoj prednosti kada bi odradio sa REST servisom.

> Sada gledam unigui, ne izgleda to loše. Imaš iskustva kako to radi na mobilnim telefonima?

Ne licno, ali interno koristi SenchaJS tako da je to sve odlicno testirano i upotrebljivo. Imas na sajtu kod njih demo verziju za mobilne aplikacije.

PHP fajl koji izvrsava socket funkcije :) 'bem li ga, budan od rano jutros, zaboravio kako se strucno zove, radio 100x za mnogo stosta kada sam preko nekih aplikacija morao da citam podatke iz baze. U sustini moze lepo da se ispegla to i sa socketom da radi, meni bi to prvo palo na pamet, mada verovatno jer ove druge opcije nisam nesto preterano koristio, a delphi sam mnogo koristio jos od osnovne skole, isao na takmicenja, osvojio mi je prvo mesto na republickom IRC klijent zahvaljujuci socketima jednom.

Istina, za prosirivanje aplikacije, pogotovu ako zeli integraciju sa tudjim APIjima bolje da ne bezi od HTMLa i slicnih tehnologija. Ja sam nekako uvek vise voleo sockete pa posle cupao ono sto mi treba i delio stringove. Delphi je, iako ga danas nazalost zbog bezanja od Pascala (fokusiran na PHP i C++/C# silom prilika) jedan od najboljih alata za izradu web servera i klijenata svakakve namene.

P.S. ja sam koristio Delphi i za izradu mobilnih aplikacija, mislim da je bio XE3 (nije "bio moj", samo sam zeleo da isprobam kako radi), potom trazio adekvatno resenje za nesto sto koristi C za multiplatform i zavrsio sa Xamarinom, koga je na ***nu zalost kupio MS. Sada je deo VStudia, cak i u community verziji. A sto se tice HTML aplikacija i wrappovanja istih da rade na vise platformi, cackao sam angularjs/ionic2 i jos neke stvari. Za to stvarno postoji mnogo besplatnih alata. Ima jedan koji me je dobro sluzio al opet, rano ustajanje mi remeti long-term pamcenje :/

Socketi su odlični za veliki broj klijenata, manju latenciju i push mogućnost. Rad sa socketima na Androidu jeste zahtevniji ukoliko nije prethodno odrađen barem jedan takav projekat. Btw. svaki Http na Androidu ide kroz socket.
@PHP predlog
Lepo je navići se na Javu, Ruby,. Not, Guju i ostale drugare ali džaba kad je u domaćoj sredini za konkurentan proizvod jedan od glavnih aduta cena. Java neće lepo da se ponaša na OpenVz pa mora barem KVM. To je za krajnjeg korisnika trošak od barem 300 jura godišnje naspram shared hostinga koji je reda 30. Ovo govorim za minimalno opterećenje i fizičku podelu klijenata na više servera. To je jedan od razloga zašto obnavljam PHP iako mi više leži Java. Sad sam se setio da ima negde na ES tema stara par godina "zašto je php mrtav jezik".

Tada se vise govorilo o tome kako Python moze da zameni javu. Imao sam priliku da radim u Pythonu kada sam isprobavao neki HP-ov test OS, posle toga par godina pauze, onda sam morao da radim nesto vestacke inteligencije u Pythonu, AIMA/neuronske mreze. Sve u svemu, svidelo mi se. Lak rad sa grafikom, dosta dobra sintaksa... Ali ipak, PHP je za mene prvi izbor za web programiranje. Olaksano je toliko da se bukvalno fokusiras samo na funkcionalnost, o gomili stvari sam PHP vodi racuna, recimo tipovi promenljivih. Prvi put sam se u PHPu susreo sa time da programski jezik sam kombinuje tipove promenljivih na nacin na koji ti zelis. Ne kazem da je u delphiju ili C++ to veliki problem s obzirom na pakete koje postoje i funkcije, ali je od samog starta jezik toliko olaksan da svako moze da ga nauci.

Necu vise offtopic, ako treba neka informacija o pomoci oko wrappovanja HTMLa i slicno za android, tu sam.

Po mom misljenju ce u narednih desetak godina uticaj/koriscenje klasicnih jezika sve vise slabiti naspram kombinacije NodeJS i JavaScript.

Hvala svima na velikoj aktivnosti u temi. Da se malo uhodam sa javom, sada isprobavam običan http sa post i request, pa ovisno kako to ide budem dalje odlučio.

@savkic, isprobao sam node, kolege ga aktivno koriste i uistinu je jako jako moćan i brz. Jedino me npr živcira da kod nas u HR niti jedan hosting ne podržava nodeJS...

Da li podrzavaju Docker? Mozda moze da ti bude povoljnije da ides na cloud.

Ma počeo se igrat već sa delphi/android. Napravio jednostavan http server u delphiu, response pišem u body. I evo, uspio dobit odgovor u androidu (koristim OkHTTP)

Malo se nećkam da li da uradim na jednostavniji način, JSON u body, to mi je sasvim dovoljno ili da se malo potrudim i napravim pravi REST. U svakom slučaju, puno hvala svima na pomoći, polako napredujem, kad završim javim šta i kako sam napravio

Vodi računa da OkHttp odbija komunikaciju ako ti istekne SSL sertifikat ili kombinuješ niže domene koje ne pokriva sertifikat za glavni domen, tjst radi na lokalu dok testiraš a dan pred istek roka u live testiranju pršte izuzeci na sve strane.
Samo cepaj dalje.

Hvala iglig. Kako kažeš, za sada cepam dalje da šta prije dođem do beta verzije, pa budem detalje rješavao