what I should use when it comes to a Web-API for server/client communication
- Utilizza un'API in stile REST su HTTP (S) (ad esempio
/customer/<key>
, /product/<key
)
- Utilizza l'applicazione / json come formato di contenuto
- Utilizza un utente / akey o uno schema di autorizzazione OAuth2 migliore
- Non cadere nella variante WS * / XML con tutti i vantaggi proclamati come contesti di sicurezza o documenti ben strutturati. YAGNI
Ho trovato utile questa guida .
what relational database system I should use
Dipende dal tuo caso d'uso specifico e dalla tua struttura web. Opzioni tipiche:
a. NoSQL come MongoDB, CouchDB - fornisce le API JSON fuori dalla scatola. Se non è necessaria alcuna logica del server diversa dalla persistenza e amp; query, forse una buona scelta
b. SQL come MySQL, PostgreSQL - i cavalli di lavoro su Internet. Ha senso solo in combinazione con un webframework. La mia preferenza: Flask basato su Python (un po 'difficile da coltivare con) o Django (un po' più difficile da iniziare, facile da coltivare) - a seconda della lingua scelta ci sono molti altri tra cui scegliere.
c. Commercial BaaS ( backend as a service ), ad es. Analizza o molti altri
I'd just need somebody to draw me a picture about how a server looks like
Ho un'esperienza ampia e positiva con il seguente stack:
In questo caso il server implementa il modello di dati come classi Python, che sono mappate dall'ORM di Django al back-end DB (backend collegabili, quindi il DB attuale è di scarsa importanza). I modelli e / o i moduli aggiuntivi contengono la business logic, che è agonistica se viene utilizzata da un client remoto o in un codice di vista lato server.
L'API REST si trova sopra questi modelli ed è fornita da diverse risorse basate su tastypie che nella maggior parte dei casi mappano 1: 1 ai modelli, in altri casi forniscono una logica di elaborazione intermedia come quando ci sono più modelli coinvolto per soddisfare una query.