Risposta in due parti: Pensieri generali e una risposta reale di seguito:
Pensieri generali
Dal contesto dell'applicazione generale, penso che dovresti specificamente non provare a fare ciò che stai chiedendo come fare. Una regola generale in cui vivo è che gli endpoint API devono sempre restituire una risposta API appropriata.
Ad esempio, la risposta di Marstato porterà certamente a ciò che stai cercando di fare, ma ci sono alcuni aspetti negativi non intenzionali che possono causare problemi lungo la strada. Principalmente, il tuo accept-header ora agisce efficacemente come parametro di routing. Cosa succede se rimuovi accidentalmente l'intestazione dalla tua richiesta in angolare in fondo alla strada? Cosa succede se un altro sviluppatore si unisce e tenta di implementare la chiamata API senza rendersi conto dell'importanza dell'intestazione di accettazione? In entrambi i casi il risultato sarà lo stesso: non riceveranno un vero o un falso, ma torneranno invece qualcos'altro. E questo sarà molto confuso.
Ancora una volta, ci sono sicuramente dei modi per fare ciò che vuoi fare, ma penso che la vera risposta sia che non dovresti davvero provare a farlo. Gli endpoint API sono solo per gli sviluppatori e qualsiasi risposta che possa potenzialmente confondere gli sviluppatori è una risposta errata e non dovrebbe essere restituita da un endpoint API.
Sì, gli utenti del tuo sito possono accedere all'URL in questione e visualizzare uno schermo bianco con "false". Tuttavia, gli endpoint dell'API dovrebbero essere raggruppati e invisibili all'utente finale, quindi non c'è davvero alcun motivo per cui qualcuno dovrebbe finire su example.com/authorized per vedere quella schermata. Separare chiaramente le tue chiamate API (ad es. Api.example.com/authorized o example.com/api/authorized) è un buon modo per ridurre al minimo le probabilità che qualcuno inciampi accidentalmente sui propri URL API, rendendo anche il sistema un po 'più organizzato.
Quindi la mia risposta generale è che la probabilità e il danno di qualcuno che inciampa accidentalmente nei propri URL API è (o dovrebbe essere) abbastanza bassa da non meritare la logica aggiuntiva nelle chiamate API, specialmente da una risposta non standard dall'API potresti confondere te stesso o altri sviluppatori lungo la strada.
Risposta effettiva
Se davvero vuoi farlo, un altro modo per farlo sarebbe quello di verificare la mancanza di credenziali di accesso. Presumibilmente la tua chiamata API è più di una semplice richiesta GET? La chiamata API restituisce vero / falso a seconda che l'utente sia autorizzato o meno, corretto? Ciò significa che la chiamata API sa quale utente è autorizzato, il che significa che le credenziali dell'utente stanno arrivando nella richiesta. Poiché stai facendo una richiesta GET, significa che le credenziali sono nell'intestazione, in un cookie o nei parametri URL. I cookie non dovrebbero essere usati per le chiamate API, quindi la migliore ipotesi è che le credenziali dell'utente siano nell'intestazione HTTP in qualche modo. Tuttavia, se un utente accede semplicemente a example.com/authorize nel proprio browser, tali credenziali non saranno presenti. Di conseguenza, si può semplicemente presumere che venga utilizzato un browser se nell'intestazione HTTP non sono presenti assolutamente credenziali utente e, in caso contrario, restituire una normale chiamata API se sono presenti credenziali. Lo stesso vale anche se si accettano le credenziali dell'utente nei parametri URL (anche se sarebbe strano).