Codice di stato "Operazione non valida" in un'API REST di HATEOAS

8

In un'API HATEOAS vengono restituiti collegamenti che rappresentano possibili transizioni di stato. Un client conforme dovrebbe semplicemente recuperare e seguire tali collegamenti, ma se un client non conforme sta costruendo URI anziché seguire i collegamenti forniti quale sarebbe il codice di stato / risposta più appropriato da restituire?

  • 400 funzionerebbe, insieme ad alcune informazioni nel corpo della risposta - questo è ciò che stiamo facendo attualmente
  • 403 Immagino che sarebbe sbagliato, poiché implica che la richiesta non potrebbe mai funzionare - ma potenzialmente il link potrebbe essere disponibile in futuro
  • 404 suoni plausibili - in questo momento la risorsa non esiste

Che cosa pensano le persone? So che le richieste condizionali sono in grado di gestire richieste basate su risposte obsolete (come ad esempio 412s), ma questa è una situazione leggermente diversa.

Aggiornamento:

OK, ora vedo che la risposta corretta per questi tipi di operazioni non valide sarebbe un 404. Come su dove la sintassi di una richiesta è corretta, sta andando a una risorsa valida ma in qualche modo sta violando una regola aziendale. Ecco un paio di esempi forzati:

  1. Diciamo che il cliente può fornire due numeri che devono essere compresi tra il 20% l'uno dell'altro, ma altrimenti potrebbe essere qualsiasi numero.
  2. Diciamo che il cliente può fornire un numero che passa attraverso alcuni calcoli il cui risultato indica che il numero originale fornito non era corretto.

400 è la risposta corretta per questi?

    
posta FinnNk 28.03.2012 - 18:27
fonte

2 risposte

5

Se c'è una possibilità che esisteranno i collegamenti in futuro, sia 400 Bad Request e 403 Forbidden potrebbe non essere corretto: le sezioni pertinenti contenute nella RFC 2616 entrambi hanno le istruzioni che il cliente NON DOVREBBE ripeti la richiesta. La differenza tra i due è che, nel caso di 400 Bad Request , il server non ha capito ciò che il cliente stava cercando di fare, mentre con 403 Forbidden il server ha compreso la richiesta, ma si rifiuta di soddisfarlo (sempre).

Se vuoi indicare al cliente che la richiesta è stata capita, ma non la gestirai al momento della richiesta (ma non avanzare pretese sulla sua gestione in futuro), 404 non trovato sarebbe la risposta più appropriata da inviare.

Se vuoi indicare al cliente che la richiesta è stata compresa, ma la richiesta non segue regole o linee guida predeterminate (come il tuo esempio di un cliente che non fornisce due numeri entro il 20% l'uno dell'altro), vuoi usare < a href="http://tools.ietf.org/html/rfc2616#section-10.4.10"> 409 Conflitto , che ha lo scopo di indicare al cliente che la richiesta deve essere corretto per essere gestito correttamente.

Tuttavia, dovresti separare la non conformità in buona fede dalla non-conformità in malafede. Se stai cercando di proteggere la tua applicazione dalle richieste di un attore cattivo, quasi sicuramente non gli interesserà quale codice di risposta invii: continueranno a costruire URL fino a quando non colpiscono qualcosa che gli piace.

    
risposta data 28.03.2012 - 18:54
fonte
2

Questi codici seguono lo standard impostato dal HTTP rfc .

In base alla sezione Definizioni dei codici di stato :

  • 400 Richiesta non valida

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

  • 403 Vietato

The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.

  • 404 non trovato

The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

Nel tuo caso, se l'URI costruito non porta da nessuna parte penso che sarebbe opportuno restituire 404 .

E se l'URI è valido ma i dati passati (come un documento json) non funzionano , allora dovresti restituire 400 .

Modifica :

Risposta al commento dell'OP: Penso che il sistema dovrebbe restituire 400 quando la sintassi e anche il significato dei dati sono interrotti.

    
risposta data 28.03.2012 - 18:41
fonte

Leggi altre domande sui tag