PHP - API / librerie interne - Che cosa ha senso?

Il tuo approccio sembra la strada da percorrere. Una singola API HTTP non è così semplice se devi fare richieste http continuamente.

Caratteristiche come "buona documentazione" e ORM saranno una necessità quando il progetto diventa più grande.

It will be very expensive performance wise. One page request will result in several additional http requests (which although local, are still ones that Apache will need to handle).

Per le chiamate interne, sono d'accordo, ma non tutte le API sono RESTful, e non tutte funzionano in modo semplice CRUD (anche se questo è il caso d'uso più comune per loro).

You'll lose all of the best features PHP has for OO development. From simple inheritance, to employing the likes of ORM which can save you writing a lot of code.

Perché? Puoi ancora utilizzare tutte queste cose in un'API. Dove pensi che il server API ottenga i suoi dati? Un'API non accede necessariamente direttamente a un database. Sembra quasi che tu stia guardando questo solo dal punto di vista del consumatore dell'API. Anche quello è imperfetto, davvero, perché ciò che il consumatore ottiene può essere uno o più oggetti, anche.

In un'architettura MVC, un'API non è molto diversa da qualsiasi altra applicazione MVC. Hai le tue opinioni - la risposta JSON. Hai i tuoi controller e i tuoi modelli. Hai a disposizione tutti gli stessi vantaggi di OOP. L'unica differenza principale è la presentazione dei dati (e probabilmente la quantità di dati che stai presentando alla volta).

For internal projects, the actual process makes me cringe. To get a users name, for example, a request would go out of our box, over the LAN, back in, then run through a script which calls a method, JSON encodes the output and feeds that back. That would then need to be JSON decoded, and be presented as an array ready to use.

Quando comunichi tra le lingue, devi convertire in qualcosa che tutto il resto capisce. Nella maggior parte dei moderni sistemi software, questo è JSON. Quando comunichi tra applicazioni della stessa lingua, puoi scegliere tra le due librerie o comunicare di nuovo in JSON.

Working with arrays, as appose to objects, makes me sad in a modern PHP framework.

Chi dice che devi lavorare con gli array con i metodi JSON di PHP? json_decode converte in un oggetto per impostazione predefinita (se vuoi un array, devi impostare il assoc flag), e se non hai un framework che già lo fa, puoi scrivere una funzione di supporto "to_json" funzione che converte un oggetto PHP in un array associativo. In alternativa, se utilizzi la versione 5.4 o successiva, puoi implementare JsonSerializable per convertire l'oggetto da codificare.

Hai detto che uno dei tuoi piani era scrivere un'applicazione mobile e una barra degli strumenti che accedessero a questo nuovo sistema. Se non si dispone di un'API, come si prevede di comunicare con tali applicazioni esterne? Non vuoi che nessuna di queste interfacce memorizzi tutto e faccia un po 'il sollevamento della tua applicazione, quindi ad un certo punto, avrai comunque bisogno di un'API.

Come per le tue applicazioni interne, dipende in gran parte dalle esatte implementazioni di ciò che già possiedi. Se hai a che fare con un certo numero di lingue diverse, fare la tua rotta significa che devi mantenere molte basi di codice diverse per la stessa cosa. Considerando che, se si fa il percorso API anche per loro, si ha una sola base di codice da mantenere, al costo di doversi connettere ad esso come se fossero entità esterne (che possono essere molto piccole, se lo si costruisce bene; su quante API è probabile che tu già usi e quanto siano la maggior parte di esse). Tieni presente, inoltre, che la rotta dell'API ti consente di spostare quelle altre applicazioni al di fuori del sito in caso di necessità. L'utilizzo del percorso della libreria probabilmente significa che è in corso un'importante modifica del codice se è necessario spostarlo fuori sede.

Bene, in fondo hai ragione. I tuoi argomenti sono validi e davvero pesanti.

Ma hanno ragione anche loro. È semplice e robusto. È disaccoppiato. Un HTTP API è la strada da percorrere, se me lo chiedi.

Ci sarebbe una terza via. Cosa ti impedisce di implementare l'API HTTP in PHP? In questo modo puoi riutilizzare tutto.

Ecco come lo farei io: avendo l'API HTTP, puoi estenderlo nella tua applicazione. Non ci sarà differenza per un modello che utilizza direttamente il database o l'API HTTP. Dopotutto, è CRUD in entrambi i casi. Sarà più lento, sì. Ma se viene eseguito nella stessa casella, non sarà un fermo di presentazione, poiché la richiesta non lascerà mai la macchina. Anche la codifica e la decodifica JSON sono abbastanza veloci.

Nell'API HTTP userei Java, usando JPA e JAX-RS. In questo modo è abbastanza semplice.

1. Le richieste HTTP locali sono economiche, le prestazioni non costano quasi nulla quando si dispone di keepalive. Se vuoi che sia più veloce, puoi usare i socket persistenti con gzencode.

2. ORM di solito sputa codice SQL orribile, che non è ottimale e questa è la cosa che ridurrà molto le tue prestazioni. Un anti-modello. E in realtà vuoi condividere questi modelli attraverso il progetto? Un piccolo cambiamento di schema in uno dei progetti dovrà essere incluso in ognuno di essi ... sarà un disastro di manutenzione.

La migliore caratteristica di un progetto è di averla costruita usando sottosistemi piccoli disaccoppiati, non una grande pila di schifezze che è strettamente integrata e che nessuno può comprendere appieno.

La cosa triste è che le persone stanno traducendo codice relazionale bello, in qualcosa di così schifoso, illeggibile e lento come classi PHP generate automaticamente, con gazillion di stupidi metodi, filtri, costanti e table shema in XML gonfiati e alla fine scrivi metà del tuo SQL manualmente perché può a malapena riuscire a fare correttamente inserimenti semplici, la maggior parte degli aggiornamenti banali e seleziona comunque con JOIN.

In realtà questo ORM può supportare qualcosa come "complicato" come multi-insert senza transazione o semplice SELECT FOR UPDATE ora? Quando ho controllato doctrine / propel l'ultima volta, tutto quello che ho ottenuto per le cose più semplici erano solo scuse stupide e il set di funzionalità supportate era così primitivo che probabilmente avrei potuto usare mysql di 10 anni fa e non me ne sarei accorto.

ORM nel 2016, quando i produttori di DB stanno inventando nuove funzionalità come pazzi e vuoi accontentarti di un codice DB da un'età della pietra? Dai.