Kako da vratim objekat prema parametru iz url-a ?

1

Kako da vratim objekat prema parametru iz url-a ?

offline
  • Lead Developer ⠀ ⠀⠀⠀⠀⠀⠀ Go 5 Creative
  • Pridružio: 14 Feb 2008
  • Poruke: 12242

Pišem Android aplikaciju koja koristi neke unikatne brojeve da definiše objekat.

Hteo bih da napravim neku "mini bazu" na mom sajtu kojoj bi moja Android aplikacija pristupila i prosledila parametar - taj int i povukla nazad objekat koji sadrži definiciju.

Nešto poput linka koji generiše informaciju o problemu prema ID-u greške.

Kako bih to mogao da izvedem i koji je pravi način da to izvedem ?

Primer :

adresa : sajt.com/aplikacija/getItemData.php

Android aplikacija prosledi parametar : sajt.com/aplikacija/getItemData.php?item=9239320
i povuče objekat nazad sa informacijama o tom broju.

Gde bih držao te objekte na sajtu ?

~ na glas razmišljam :
Funkcija pokupi URL, ekstraktuje parametar, proveri da li postoji podatak za taj parametar, ako postoji vrati neki objekat koji pokupi moja aplikacija i to je to.

Ovo sam testirao sada Mr. Green
<?php      echo $_GET['itemID']; ?>

Bez frke pokupim parametar.

P.S. Noob sam kada je php u pitanju a ova skripta bi bila na sajtu kod mene, pa mi je bitno da koristim koliko-toliko siguran način da ovo uradim, kako neko ne bi lako pristupio celom sajtu.

Nisam siguran koliko je pametna ideja da držim u samoj skripti podatke o objektu, pa da ih ispišem samo i pokupim ... Sigurnost samih podataka nije bitna.

Hvala.



Registruj se da bi učestvovao u diskusiji. Registrovanim korisnicima se NE prikazuju reklame unutar poruka.
offline
  • Milan
  • Pridružio: 17 Dec 2007
  • Poruke: 14249
  • Gde živiš: Niš

A kako šalješ zahtev serveru? Odakle? U pitanju je nativna Android aplikacija ili hibridna, odnosno Java ili JS? I što ne bi podatke čuvao u bazi?

Inače, mislim da bi najbolje bilo da objekat vraćaš kao JSON. Ako je u pitanju JS, lako ćeš da ga isparsiraš i dobiješ isti objekat na klijentskoj strani, a ako je u pitanju Java možeš da koristiš neku biblioteku za Javu koja može da parsira JSON. Pogodnost je i to što objekte možeš da čuvaš takođe direktno i json formatu, i nema potrebe uopšte da razmišljaš o perzistenciji. Very Happy



offline
  • Lead Developer ⠀ ⠀⠀⠀⠀⠀⠀ Go 5 Creative
  • Pridružio: 14 Feb 2008
  • Poruke: 12242

Napisano: 27 Apr 2016 16:27

Pišem programče preko Xamarina.

Testirao sam upravo sada kod koji sam koristio u .NET-u, za deserijalizaciju XML-a sa linka.
To radi pa bih, kako mi je XML područje malo poznatije, koristio XML radije nego JSON.

Dakle stranica sada treba da generiše XML fajl prema parametru koji se prosledi.

Šta bi mi trebalo da napravim neku bazu na sajtu ?

Uzevši u obzir da sajt hostuje MC, ne bih da smaram Pecu da dodatno konfiguriše to sve ako bude potrebno.
Možda mogu da pogledam Dropbox pa da tamo hostujem aplikaciju koja će ovo raditi.

Ja ću u međuvremenu da proučim malo XMl serijalizaciju u php-u i probaću da napišem malu skriptu koja prema parametru ispisuje generisani XML. To sve ću da probam da povučem aplikacijom i ako uspem, ostaje samo pitanje skladištenja te baze.

Dopuna: 27 Apr 2016 18:03

Previše mi je kompleksna ova php serijalizacija XML-a, pa sam našao obilaznicu.

<? header('Content-type: text/xml'); $xml = <<<EOT <?xml version="1.0" encoding="utf-8"?> <UpdateFile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">   <appVersionID>_APPVERPLACEHOLDER</appVersionID>   <message>Have a nice day!</message> </UpdateFile> EOT; $temp = str_replace("_APPVERPLACEHOLDER","44", $xml, $i); echo $temp; ?>

Nešto na tu foru. Predefinisani XML, placeholder za promenljivu itd.

Sa Androida :
 newVersionInfo = (UpdateFile)xmlSerializer.Deserialize(XmlReader.Create(@".../getItemData.php?itemID=2424"));            

I to radi. Ako bude potrebno mogu sam XML da povučem u php fajlu sa mog dropbox-a, gde već imam veću kontrolu preko Dropbox API-a itd.

Dakle sada sam rešio taj deo priče i znam da povučem prosleđeni parametar.

Ostaje samo pitanje :

Kako da obradim te podatke tj. gde da ih skladištim, šta mi je potrebno za bazu itd.
Da li bih bazu mogao da držim na dropboxu recimo ?
Tamo bih isto mogao da skladištim slike proizvoda i umesto same slike, da vratim link preko objekta uređaju, pa da uređaj povuče sliku sa linka.

offline
  • Pridružio: 25 Jan 2004
  • Poruke: 2784
  • Gde živiš: Niš

Srki94 ::Napisano: 27 Apr 2016 16:27
Kako da obradim te podatke tj. gde da ih skladištim, šta mi je potrebno za bazu itd.
Da li bih bazu mogao da držim na dropboxu recimo ?
Tamo bih isto mogao da skladištim slike proizvoda i umesto same slike, da vratim link preko objekta uređaju, pa da uređaj povuče sliku sa linka.


Koliko razumem, nemaš komplikovane zahteve, tako da izaberi DBMS sa kojim misliš da ćeš najlakše da se snađeš što se tiče organizacije objekata/šeme u bazi ili čiji ti query language izgleda jednostavno. Ako nemaš nikakve relacije, siguran sam da ćeš najlakše da prođeš sa nekom od novih NoSQL baza ... samo je pitanje platforme na kojoj radiš, odnosno gde ćeš da digneš taj server Smile

Ako sam te dobro razumeo, ti si zamišljao da koristiš DBMS i kao file storage? Izvini ako te pogrešno razumem, ali za svaki slučaj - DMBS obično nisu zamišljeni da čuvaju podatke fajlove u svom storage-u ... nebitno da li kao binary ili nekako encoded. Viđao sam slučajeve gde ljudi trpaju BLOB slike u MySQL, jer postoji opcija za tako nešto, ali jednostavno nije preporučljivo zbog performansi. To se maltene radi samo ako imaš neki baš specifičan slučaj i nemaš izbora, ali opet mislim da strukturalno bolje rešenje uvek postoji a naročito ako tek kreiraš arhitekturu aplikacije/servisa.

Dropbox može da ti služi samo kao file storage, preko čijeg API-a ćeš da uploaduješ i preuzimaš slike.
Dakle, kreiraš backend u PHP-u kao jedan endpoint kako si već zamislio i preko njega uploaduješ slike na Dropbox koji ti vraća URL slike koji ti zapisuješ sa sve objektom u MySQL npr.
Ne znam kako je zamišljena ta aplikacija, ali samo ti preostaje taj interfejs za upload koji može da bude i web stranica, a možeš i preko mobilne aplikacije gde ti naravno treba više povezivanja i koja biblioteka Smile

Čini mi se da se ti već dobro inženjerski snalaziš, samo ti je problem sintaksa PHP-a Very Happy

offline
  • Peca  Male
  • Glavni Administrator
  • Predrag Damnjanović
  • SysAdmin i programer
  • Pridružio: 17 Apr 2003
  • Poruke: 23065
  • Gde živiš: Niš

1. savet: koristi JSON umesto XML (lakši je za rad, mnogo)
2. savet: čuvaj objekte u fajlovima, ne u bazi (brže je, mnogo)

offline
  • Pridružio: 25 Jan 2004
  • Poruke: 2784
  • Gde živiš: Niš

Pecin 2. savet je samo u slučaju ako ne planiraš da se taj fajl često parsira i da ne bude veliki (ne znam o kojim ciframa mogu da pričam, sve zavisi i od samog servera, ali očigledne stvari su u pitanju). U drugom slučaju moraš da ga keširaš nekako ... npr. memcached se koristi za takve stvari.
Osim toga, čak i veliki fajlovi u RAM-u nisu baš poželjna stvar, pa bi morao da ga chunk-uješ na nekoliko manjih a uobičajeno se to radi po vremenskim serijama i onda ćeš na kraju doći do nečeg što bi već imao sa npr. Mongo DB-om Razz

Srki94 ::
P.S. Noob sam kada je php u pitanju a ova skripta bi bila na sajtu kod mene, pa mi je bitno da koristim koliko-toliko siguran način da ovo uradim, kako neko ne bi lako pristupio celom sajtu.

Nisam siguran koliko je pametna ideja da držim u samoj skripti podatke o objektu, pa da ih ispišem samo i pokupim ... Sigurnost samih podataka nije bitna.

Hvala.


Zaboravih na ovo pitanje...
Ne znam onda šta ti je bitno da bude sigurno ako ti nije bitno da li će neko doći do podataka?
Ako bi ovaj php mehanizam radio zasebno ali na istom sajtu (domenu) gde već imaš neki zaseban mehanizam, ako nemaju dodirnih tačaka (osim fajl sistema) nemaš o čemu da brineš.

Što se tiče korišćenja istih root foldera oba sajta i istih fajl sistem privilegija, i ako je Linux u pitanju, najbolje je da da samo povedeš računa da ne dozvoliš da neko može da uploaduje php fajl (to možeš da sprečiš sa npr. MIME type proverom) jer neko lako može da uploaduje ceo FS browser (aka php shell) i da vršlja dalje po fajlovima, do nivoa do kojeg su privilegije ownera za te fajlove dozvoljene i/ili ako user sa kojim se izvršavaju php procesi za taj sajt nije jailovan/chrootovan, odnosno nije mu setovan Open Base pa tako može da hakuje i ceo server Very Happy
Ako kreiraš taj svoj backend RESTful API na pod-domenu, onda ćeš moći i jedno i drugo da izoluješ.
U slučaju da su na istom domenu a samim tim i root folderu (i sajt i restful api), mislim da ćeš teško moći da razgraničiš privilegije i jail-ovanje.

Oko sanitizovanja inputa kod PHP-a se već milion puta govorilo. Vrlo lako ćeš da pronađeš šta je sve potrebno da uradiš, a uglavnom su jednolinijske wrapper funkcije koje možeš da pohvataš za vrlo kratko vreme ako već smatraš da tvoj backend neće ići u neku veliku kompleksnost Wink

offline
  • Lead Developer ⠀ ⠀⠀⠀⠀⠀⠀ Go 5 Creative
  • Pridružio: 14 Feb 2008
  • Poruke: 12242

Peca ::
2. savet: čuvaj objekte u fajlovima, ne u bazi (brže je, mnogo)


Da li to recimo podrazumeva ovakav pristup :

processRequest.php -> proveri prosleđeni parametar i proveri da li fajl postoji na serveru, ako postoji vrati taj fajl
Fajl je samo serijalizovani objekat u nekom folderu na serveru

Citat:Pecin 2. savet je samo u slučaju ako ne planiraš da se taj fajl često parsira i da ne bude veliki (ne znam o kojim ciframa mogu da pričam, sve zavisi i od samog servera, ali očigledne stvari su u pitanju). U drugom slučaju moraš da ga keširaš nekako ... npr. memcached se koristi za takve stvari.

Sam objekat sadrži nekoliko kraćih stringova i jedan DateTime. Ne držim u objektu byte[] slike, već samo url ka fajlu na Dropboxu. (Ujedno odgovor na pitanje od ranije) Veličina je oko 4KB.

E sada, koliko bi se slao taj objekat ...
Svaki put kad korisnik doda proizvod preko aplikacije, pošaljem zahtev serveru da vidim da li imam informacije o tom proizvodu i vratim neku informaciju.

Ne bih rekao da će prosečan korisnik imati više od ~ 10-15-20 fajlova u svojoj bazi, ali ako uzmemo u obzir šansu da aplikacija zaživi i da ima ogroman broj korisnika ... Very Happy

Biće sigurno više od 100 objekata na sajtu koje ću napraviti ja uz pomoć nekih prijatelja a kad uzmemo u obzir da svaki korisnik može da doda proizvod koji ne postoji u bazi, ta cifra lagano može da postane ogromna ubrzo.

Citat:Zaboravih na ovo pitanje...
Ne znam onda šta ti je bitno da bude sigurno ako ti nije bitno da li će neko doći do podataka?


Podaci kao podaci nisu bitni uopšte. To su samo informacije o proizvodu, koje možeš da nađeš gde god da pogledaš. Ništa privatno ili bitno za korisnika, niti ima veze sa kranjim korisnikom. Jedino ako pogledamo iz ugla zloupotrebe - da neko ubaci exploit unutar objekta i da ja to vratim krajnjem korisniku. Donekle ću se od toga osigurati proverama i ograničenjima ali sigurno postoji mnogo toga što ne znam.

Mislio sam na sajt uopšteno, jer trenutno to držim na mom sajtu u custom folderu unutar root foldera CMS-a. Eto sada si napisao da mogu da bacim to na poddomen pa ću najverovatnije tako i uraditi Smile

Nisam mnogo upućen u Web deo priče uopšte, možda sam samo ostavio drugačiji utisak.
Nisam nikada nešto slično pisao za web.

Uglavnom ako je dobar Pecin predlog za moj slučaj sada kada je jasno kako to sve izgleda, ja bih na tu foru ovo radio. Jednostavnije je čini mi se ? Very Happy


P.S. hvala svima na savetima Ziveli

Edit : 23:42
Za sada sam pomerio vraćanje objekta u novi php fajl. Tamo imam funkciju koja vraća niz sa podacima prema prosleđenom parametru (proverim prosleđeni parametar uslovima) . Iz php fajla kom pristupa Android pozovem tu funkciju, ona vrati niz kao jedan od parametara str_replace funkcije, koja zameni predefinisana polja predefinisanog XML-a. To će mi služiti dok pišem aplikaciju, pa ću kasnije da ga zamenim ovim sistemom koji je predložio Peca ili nekom bazom.

offline
  • Milan
  • Pridružio: 17 Dec 2007
  • Poruke: 14249
  • Gde živiš: Niš

Peca ::2. savet: čuvaj objekte u fajlovima, ne u bazi (brže je, mnogo)A ako odabere neku in-memory bazu? Kao recimo Redis? Very Happy Server se pokreće bukvalno jednim dvoklikom na exe fajl, i baza je odmah aktivna i spremna za rad. Može i da ga gađa direktno iz Android aplikacije, bez posrednika. Brže od toga ne može... Very Happy

offline
  • Pridružio: 25 Jan 2004
  • Poruke: 2784
  • Gde živiš: Niš

Napisano: 29 Apr 2016 13:31

vasa.93 ::Peca ::2. savet: čuvaj objekte u fajlovima, ne u bazi (brže je, mnogo)A ako odabere neku in-memory bazu? Kao recimo Redis? Very Happy Server se pokreće bukvalno jednim dvoklikom na exe fajl, i baza je odmah aktivna i spremna za rad. Može i da ga gađa direktno iz Android aplikacije, bez posrednika. Brže od toga ne može... Very Happy

Da da da, i ja se setih Redisa u jednom trenutku ali mi je pao na pamet samo kao bolja varijanta Memcacheda sa key/value šemom, a u suštini njemu bi Redis skroz odgovarao za početak jer neće imati preopterećujuću količinu podataka a Redis plus ima i opciju da čuva sve na hard disku (jedino je frka možda oko toga što to ne radi na svaki write već na neko određeno vreme).


Srki94 ::Da li to recimo podrazumeva ovakav pristup :

processRequest.php -> proveri prosleđeni parametar i proveri da li fajl postoji na serveru, ako postoji vrati taj fajl
Fajl je samo serijalizovani objekat u nekom folderu na serveru


Ye, samo ne moraš da kreiraš po jedan fajl za svaki objekat. Ja sam zato i napisao da resursno može biti opterećujuće ako jedan poveći fajl non stop parsiraš (i write i read). U drugom slučaju ćeš sigurno do neke mere da optimizuješ to ako rasparčaš sve objekte na po jedan fajl, ali onda ćeš kod lociranja konkretnog objekta zavisiti samo od ID-a koji upišeš u nazivu fajla (ili čime god budeš identifikovao obejkte). Možda još nešto tu trenutno propuštam, pa razmisli detaljnije o svim opcijama svakako.

Dopuna: 29 Apr 2016 13:40

Zapravo Redis ima 2 načina za data persistence:
- RDB - Kreira se snapshot cele baze kao novi fajl svaki put, na određene intervale i verovatno imaš da odrediš auto-prune zastarelih, odnosno da odrediš fiksan broj nagomilavanja snapshotova.
- AOF - Apdejtuje jedan fajl na svaki write. Problem? Data može da postane corrupted a samim tim i poslednja verzija ovog backupa - tako da se preporučuje i jedan i drugi persistence istovremeno.

http://redis.io/topics/persistence
http://oldblog.antirez.com/post/redis-persistence-demystified.html

Dopuna: 29 Apr 2016 15:41

vasa.93 ::Može i da ga gađa direktno iz Android aplikacije, bez posrednika. Brže od toga ne može... Very Happy

I to je super ideja! Samo što nisam siguran kako će da hendluje povezivanje sa Dropbox API-em. Može da napravi poseban php API za upload, koji popunjava Redis novim objektima a da mobilna aplikacija direktno pristupa Redisu. To bi bilo u suštini i najlakše.

http://redis.io/clients#java

Dopuna: 29 Apr 2016 17:05

I još jedna stvar:

- "Dropbox public links have a bandwidth limit. 20 GB/day for Free and 200 GB/day for Pro." https://www.dropbox.com/en/help/4204

- Amazon AWS Free Tier includes 5GB storage, 20,000 Get Requests, and 2,000 Put Requests with Amazon S3.
https://aws.amazon.com/s3/

offline
  • Lead Developer ⠀ ⠀⠀⠀⠀⠀⠀ Go 5 Creative
  • Pridružio: 14 Feb 2008
  • Poruke: 12242

Android aplikacija može da okači fajl preko Dropbox API-a i moje Dropbox aplikacije, da povuče link uploadovanog fajla i da ga smesti u objekat. Svejedno ću imati neku sync mogućnost lokalne baze korisnika, pa mi je "usput" Dropbox API.

Taj objekat prosledim bazi na neki način nakon uploada.

Samo što neću odmah da ubacim u bazu podatke, nego ću da ih zadržim dok se ne provere, pa ću naknadno da ubacim u javni deo svaki unos koji je legitiman.

Nisam znao za to ograničenje na Dropboxu Confused
Tnx.

Ko je trenutno na forumu
 

Ukupno su 466 korisnika na forumu :: 31 registrovanih, 1 sakriven i 434 gosta   ::   [ Administrator ] [ Supermoderator ] [ Moderator ] :: Detaljnije

Najviše korisnika na forumu ikad bilo je 2413 - dana 03 Okt 2019 05:07

Korisnici koji su trenutno na forumu:
Korisnici trenutno na forumu: A.R.Chafee.Jr., Alojz Hauptman, awathorn, Boris902, branko72, bulovic, Davor Kondic, dejoglina, Dorcolac2, Georgius2, hyla, ivan979, ivance95, kolateralnasteta, Kubovac, lakiluciano, liman2, Marko Marković2, Metanoja, MikeHammer, Mixelotti, Profica2, radoznao2, RecA2, repac2, samsung2, t84dar, vlad the impaler, vlvl, zdrebac2, |_MeD_|