HTTP overhead in API-centric PHP application -

i reorganizing existing php application separate data access (private api calls) application itself.

the purpose of doing allow application on intranet access same data without duplicating code run queries , such. planning make easier developers write code current web application, while few team members adding features api.

currently application has structure (this 1 of many pages):

• get /notes.php - gets page user view notes (main ui page)
• get /notes.php?page=view&id=6 - contents of note 6
• post /notes.php?page=create - create note
• post /notes.php?page=delete - delete note
• post /notes.php?page=append - append note

the reorganized application have structure this:

• get /notes.php
• internal /api/notes/6
• internal post /api/notes
• internal delete /api/notes/6
• internal put /api/notes (or perhaps patch, depending on whether full representation sent)

in web application thinking of doing http requests urls on https://localhost/api/ seems expensive. here code elaborate on mean:

// notes.php  switch ($_get['page']) {     case 'view':         $data = \requests::get(             "https://localhost/api/notes/{$_get['id']}",             array(),             array('auth' => ... )         );         // things $data if necessary , send browser         break;     case 'create':         $response = \requests::post( ... );         if ($response->status_code === 201) {             // things         }         break;     // etc... } 

i read this discussion , 1 of members posted:

too overhead, not use network internal communications. instead use more readily available means of communications between different process or have you. depends on system running on of course...now can mimic rest if not use http or network internal stuff. thats throwing whale mini toilet.

can explain how can achieve this? both web application , api on same server (at least now).

or http overhead aspect of negligible concern?

making http requests directly javascript/browser api not option @ moment due security restrictions.

i've looked @ 2 answers in this question nice elaborate on that.

the http overhead significant, have go through full page rendering cycle. include http server overhead, separate process php execution, os networking layer, etc. whether negligible or not depends on type of application, traffic, infrastructure, response time requirements, etc.

in order provide better solution, need present reasoning considering approach in first place. factors consider include current application architecture, requirements, frameworks used, etc.

if security primary concern, not way go in first place, need store session related data in yet layer.

also, despite additional overhead, final application potentially perform faster given right caching mechanisms. depends on final solution.