Le applicazioni Web utilizzano HTTP come livello di trasporto o contano come parte integrante del server HTTP?

Question

Le applicazioni Web utilizzano HTTP come livello di trasporto o contano come parte integrante del server HTTP?

#1 da (2 voti)
#2 da (1 voti)

1

Dato un server HTTP (ad esempio Apache, IIS) e un'applicazione Web (codice utente in esecuzione nel server utilizzando PHP, ASP.NET e simili), quale di questi può decidere quale codice di stato HTTP restituire per qualsiasi richiesta?

O piuttosto, una "web application" deve essere interpretata come parte integrante di "server" come utilizzata negli RFC HTTP? Quest'ultimo (RFC 7230) è piuttosto corto su questo:

An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.

Poiché la risposta effettiva è generata da un'applicazione web (escluse le risorse statiche), direi che l'applicazione web è parte reale del server.

Tuttavia, a parte l'eterno "quale codice di stato HTTP da utilizzare nelle [situazioni arbitrarie]?" discussioni, c'è anche la discussione "Se le applicazioni web usano anche i codici di stato HTTP? ", a cui vorrei una risposta normativa.

Vedi ad esempio l' API REST di Google Maps . Restituiscono 200 per ogni risposta, che può essere interpretata come "La richiesta è terminata sul server HTTP, quindi quella parte è andata su OK (200)" . Qualsiasi errore applicazione che si verifica nel corpo del messaggio come stato JSON, fino al punto NOT_FOUND .

È corretto? Non dovrebbe una richiesta di GET /Clients/123 restituire un 404 quando quel client non esiste? Allora che dire di GET /clients.php?id=123 , supponendo che esista clients.php ?

O 404 significa veramente "Non so cosa stai cercando di fare, ma non ti servirò una risorsa in quanto non ci sono risorse a (una parte di ) quell'URI "," risorsa "che significa" un file (o routing) ", che dovrebbe essere restituito dal server solo quando qualcuno ha dimenticato di implementare l'applicazione ClientService?

Il codice di stato funziona solo per la parte HTTP delle cose, o è una parte dell'applicazione Web del server, consentendo di utilizzare i codici di stato appropriati dove si adattano, utilizzando i codici di stato HTTP come codici di risposta API?

rest http layers http-response

posta CodeCaster 22.01.2015 - 11:32

fonte

2 risposte

1

Quando si tratta di codici di stato HTTP, il livello di astrazione su cui riflettere è il contesto della richiesta HTTP appena creata.

Se il tuo cliente fa una richiesta

GET http://example.com/someresource

il tuo cliente sta dicendo

Yo! example.com! Give me a representation of "someresource"

Se il client non può farlo, non restituire 200 (OK). Quello che Google fa è sbagliato. Dicendo "OK! Non posso farlo" è una risposta confusa.

Immagina di essere entrato in un negozio e mi hai detto di darmi una confezione da 6 e il negoziante ha detto "Ok ecco qua" e poi quando hai guardato nella tua borsa c'era una lettera che diceva "Mi dispiace, tutto fuori di birra "!

Al cliente non interessa il funzionamento interno di example.com, nello stesso modo in cui non ti importa dei problemi che il negozio potrebbe o non potrebbe avere. Ti importa se riesci a prendere la birra.

Se non riesci a prendere la birra, ti interessa solo se hai fatto qualcosa di sbagliato ("Scusa, ho bisogno di un documento d'identità") o se non c'è niente di più che puoi fare ("Scusa siamo tutti senza birra" o "Scusa questo è un negozio di maglieria, non vendiamo birra "). Le scuse non posso darti che le risposte alle risorse sono 4xx e 5xx

Se example.com deve parlare con 100 server o database diversi per fare ciò che il cliente ha chiesto al cliente non gliene importa, più di quanto ti interessi se il negoziante deve gridare tramite l'interfono "Hey! più birra!" per darti la birra Non ti interessa, ti importa della birra.

risposta data 23.01.2015 - 13:19

fonte

Leggi altre domande sui tag rest http layers http-response

Differenza tra lavori e lavoratori del server? Come far fare qualcosa al mio programma quando compare un errore invece di bloccarsi?

score 2 · Accepted Answer

404 significa "la risorsa richiesta non esiste". Spetta al server decidere quando tale risposta è appropriata. Apparentemente Google l'ha interpretato come "la tua richiesta API era malformata". Altre API REST potrebbero anche interpretarlo come "la tua richiesta era ben formata, ma stai chiedendo qualcosa che non esiste". Questo è il motivo per cui devi leggere i documenti API.

Il "server", a sua volta, è (come indica la quota RFC) qualsiasi cosa risponda alle richieste HTTP in modo appropriato. Se si costruisce un server da un gigantesco framework di applicazioni Web, è affar tuo. L'unico requisito è che il client ottenga la risposta semanticamente corretta in una determinata situazione. Accade spesso che l'applicazione web sia più adatta a prendere quella decisione rispetto al comportamento fuori dal comune (diciamo) di Apache, ma è possibile e dovrebbe configurarlo in qualsiasi modo abbia più senso per la propria situazione.