Aplikacja desktopowa dedykowana pod stronę w PHP

Dzień dobry,
Zrobiłem stronę w PHP i MySQL. Wygląd zakodowany w XHTML i CSS.

Strona pozwala założyć konto, logować się, wrzucać obrazki...

Chciałbym zrobić dedykowaną dla tej strony aplikację desktopową, w której można się zarejestrować, zalogować i wrzucać obrazki.

Na pewno bezpośrednie połączenie z bazą odpada, nie chce danych do bazy w exeku.

Czy "wywoływanie" skryptów PHP z poziomu aplikacji w C++ to dobry pomysł?
Mi się wydaje prymitywny, ale nie mam pomysłu na nic bezpiecznego i prostego.

Odpada stawianie jakichkolwiek dodatkowych usług na hostingu, jest to zwykły hosting z php i mysql.

Utworz sobie skrypty, ktore na podstawie parametrow GET/POST beda wykonywac okreslone zadania i zwracac tylko niezbedne informacje - bez zadnych arkuszow css, skryptow js itp. itd. Zastanow sie takze nad formatem zwracanych wynikow - wydaje mi sie ze JSON moglby byc dobrym kandydatem.

Zadaniem aplikacji desktopowej bedzie wchodzenie pod wyznaczone adresy url, pobieranie danych oraz ich parsowanie.

Dobrze pomyślane. Tylko po co JSON czy jakieś inne formaty?

Ja myślę np. tak:

Wysyłam POST do skryptu np. login.php z parametrami login i zahaszowane haslo. I wystarczy wtedy, że skrypt wyświetli 0 lub 1:
0 - uzytkownik nie istnieje/zle dane
1 - zalogowano pomyslnie

Chyba, że ten JSON np. jakbym chciał wyświetlić wrzucone obrazki przez użytkownika to wtedy tak.

No i myślę, że nie muszę wbudowywać tego w normalne skrypty strony tylko utworzyć katalog /api_for_desktop/ i w nim register.php, login.php itd.

@mcoder:
Jeżeli masz zwracać tylko stany typu true/false to ok, json niepotrzebny.

Z drugiej strony - czasem będziesz chciał zwrócić więcej danych - wtedy zostaje json/inne wynalazki, z tym, że json jest chyba najwygodniejszy.

Jeżeli czasem masz zwracać więcej danych, czasem tylko stan true/false - używaj jsona i tak, będzie to bardziej spójne. Najlepiej niech Twój json zawsze ma element status, a obok tego coś więcej (np. kod dlaczego coś się nie powiodło, albo jeżeli coś się powiodło - dane, które powinny być zwrócone).

A przy logowaniu i tak warto zwrócić np. wszystkie dane o koncie użytkownika - tj. dane z profilu itd - login przesyłasz do logowania - to już go znasz, ale pełne dane (imię/nazwisko), link do avatara itd. pasowało by zwrócić razem ze statusem sukcesu.

mcoder napisał(a):

Dobrze pomyślane. Tylko po co JSON czy jakieś inne formaty?

Ja myślę np. tak:

Wysyłam POST do skryptu np. login.php z parametrami login i zahaszowane haslo. I wystarczy wtedy, że skrypt wyświetli 0 lub 1:
0 - uzytkownik nie istnieje/zle dane
1 - zalogowano pomyslnie

Jezeli planujesz zwracac dane w postaci "0" i "1" to moze rzeczywiscie nie ma sensu bawic sie w uzywanie JSON-a. Jezeli jednak danych byloby wiecej to wtedy zmieniloby to postac rzeczy.

Swoja droga to nie wiem czy dobrym pomyslem jest zwracanie 0 lub 1. O ile zwrocona jedynka jest jeszcze ok, to podczas zwracanego zera nie wiesz co sie stalo. Dobrze byloby gdyby klient wiedzial co jest przyczyna takiego stanu rzeczy. Przynajmniej nie wyswietlisz uzytkownikowi informacji, ze nie mozna sie zarejestrowac z powodu dublikatu loginu podczas gdy problem lezy zupelnie gdzie indziej.

Jezeli nie chcesz uzywac formatu typu JSON i wolisz zwracac liczby, to proponowalbym przyjac 0 jako kod sukcesu, a kolejne liczby jako kody bledow.

mcoder napisał(a):

Chyba, że ten JSON np. jakbym chciał wyświetlić wrzucone obrazki przez użytkownika to wtedy tak.

Jezeli wezmiemy pod uwage wynik zwracany podczas logowania i porownamy go do wyniku zwracanego w sytuacji kiedy chcesz wyswietlac obrazki, to mozna dojsc do wniosku ze formaty typu JSON nie sa do logowania potrzebne, ale do wyswietlenia obrazkow juz tak.

Jest byc moze w tym jakas racja, jednak ja jestem raczej zwolennikiem spojnosci. Jezeli planujesz rozwijac swoja aplikacje to mysle, ze dobrym pomyslem jest zdecydowac sie na jeden format. Moze to subiektywna opinia ale to troche takie dziwne jak API zwraca raz JSON-a raz czyste dane, raz cos innego. No ale decyzja zalezy od Ciebie. Na pewno zwracanie suchej liczby jest prostsze i poczatkowo mniej jest z tym problemow.

mcoder napisał(a):

No i myślę, że nie muszę wbudowywać tego w normalne skrypty strony tylko utworzyć katalog /api_for_desktop/ i w nim register.php, login.php itd.

Zgadza sie, nie ma sensu wbydowywac tego w normalne skrypty. Jednak nie ma sensu nazywac tago api_for_desktop poniewaz byc moze za jakis czas bedziesz chcial zrobic klienta w postaci aplikacji mobilnej. Lepiej myslec przyszlosciowo i utworzyc katalog typu api, webapi itp.