Come distinguere quando lo stato 404 è reale nel servizio RESTFul

Question

Come distinguere quando lo stato 404 è reale nel servizio RESTFul

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

0

Abbiamo ServiceA con questi endpoint definiti:

/devices:
  get:
    queryParameters:
      make:
        type: string
        repeat: false
        required: false
      model:
        type: string
        repeat: false
        required: false
    responses:
      200:
        body:
            schema: Devices
        500:
          body:
               text/plain:
  /{deviceId}:
    uriParameters:
      deviceId:
    get:
      responses:
        200:
          body:
            schema: Device
        404:
          body:
               text/plain:
        500:
          body:
               text/plain:

Se nessun dispositivo corrisponde a una richiesta di / dispositivi? make = x & model = y, viene restituito un elenco vuoto di dispositivi con uno stato 200. Se nessun dispositivo corrisponde a una richiesta di / devices / badDeviceID, viene restituito un 404.

Abbiamo un altro servizio che chiama questo. Il problema che stiamo riscontrando è che vogliamo restituire un errore di 500 servizi dal secondo servizio se il primo servizio è inattivo. Se un 404 viene restituito dal server per le chiamate a / devices? Make = x & model = y, sappiamo che il servizio è in realtà inattivo / irraggiungibile. Ma per le chiamate a / devices / badDeviceID, non possiamo sapere se il dispositivo non esiste o il servizio è inattivo.

Qualcun altro ha avuto questa situazione? Come l'hai gestito?

I nostri servizi sono scritti in Java e distribuiti in un contenitore di applicazioni, nel nostro caso JBoss EAP. Se EAP è attivo e in esecuzione ma il servizio individuale non è distribuito o attualmente disabilitato, EAP restituirà un 404 al chiamante. In questo caso non possiamo distinguere da quando il servizio è distribuito / disponibile e la risorsa non può essere trovata.

rest http-response

posta sdoca 15.03.2018 - 16:06

fonte

2 risposte

Leggi altre domande sui tag rest http-response

È possibile aggiungere il livello di servizio nel pattern MVC? Hosting di quello che normalmente sarebbe un servizio Windows all'interno di un server web

score 2 · Answer 1

In base alla descrizione, si restituisce un errore 404 nella situazione in cui il servizio è inattivo o irraggiungibile. Questa non è una risposta appropriata per quella situazione. Gli errori 4xx riguardano problemi con la richiesta dell'utente. La situazione in cui un servizio è inattivo o irraggiungibile dovrebbe essere un errore 5xx.

Sulla base dei dettagli extra che hai fornito, penso che puoi gestirlo mappando in una semplice app in un contesto meno specifico. Ad esempio, supponi che l'app per dispositivi sia mappata sul server a app/devices . È possibile creare un'applicazione banale mappata a app che restituisce semplicemente un errore di "servizio scaduto" di 500 classi. Quando l'app dei dispositivi è in esecuzione, sarà più specifica e gestirà le richieste. Se non è lì, la tua app web "service down" prende il sopravvento.

score 0 · Answer 2

Non restituire un codice di errore 404, restituire null

Come hai scoperto, i codici di ritorno HTTP sono utilizzati dal livello del protocollo http, non dal livello dell'applicazione. Restituisce un contenuto 200 e null o genera un'eccezione e restituisce 500 se l'id del dispositivo non viene trovato.