Validierungsfehlerantworten in der REST-API

Question

Ich entwerfe eine RESTful-API und frage mich, welches das beste Format für Validierungsfehlermeldungen ist.

Zum Beispiel akzeptiert meine Kontoerstellung Endpunkt ein JSON-Objekt:

{ 
    code: 400, // HTTP code 
    message: "Validation failed", // general message 
    type: "validation_failed", // there are other types of errors as well 
    errors: WHAT_DO_I_SHOW_HERE 
} 

Ich habe mehrere Möglichkeiten für die Validierung Fehlermeldungen:

user: { 
    first_name: string, 
    last_name: string, 
    address: { 
    street: string, 
    city: string, 
    zip_code: string 
    } 
} 

Meine Antworten in folgendem Format sein werden

Format 1

errors: { 
    last_name: "First name is required", 
    address: { 
    zip_code: "ZIP code is invalid" 
    } 
} 

oder die Fehler abzuflachen, wie in Format 2

errors: { 
    last_name: "First name is required", 
    "address.city": "City is required", 
    "address.zip_code": "ZIP code is invalid" 
} 

oder ein Array verwenden, wobei jedes Element kann Feldnamen, Fehlercode, Fehlermeldung, verschachtelte Fehler usw.

errors: [ 
    { 
    field: "first_name", 
    message: "First name is required", 
    }, 
    { 
    field: "address", 
    errors: [ 
     { 
     field: "zip_code", 
     message: "ZIP code is invalid" 
     } 
    ] 
    } 
] 

oder

errors: [ 
    { 
    field: "first_name", 
    message: "First name is required", 
    }, 
    { 
    field: "address.zip_code", 
    message: "ZIP code is invalid" 
    } 
] 

Anscheinend ist der Array-Format ist flexibler, da Feldnamen optional ist, so kann es Fehler in einer Kombination von mehreren fiel bezogen zubringen ds (z.B. muss die Endzeit eines Zeitintervalls nach der Anfangszeit liegen). Aber meine Frage ist, welche wäre für API-Nutzer einfacher zu konsumieren?

Answer 1

Für mich in Front-End-HTML arbeiten, würde ich lieber Fehlerformat 2 flacher machen. Es wird leicht für mich sein, es zu untersuchen, oder einfach auf einen Fehler zu zielen anzuzeigen.

öffnen hören andere Meinung

Answer 2

So Ihre Kunden würden den HTTP-Statuscode zu überprüfen, und wenn es nicht 200 OK ist, würden sie in Fehler suchen müssen und deserialisieren, dass JSON in das Modellobjekt? Was passiert, wenn ein anderer Fehler auftritt (z. B. ein BadRequest, ein Konflikt oder ein DB-bezogener Fehler)?

Warum nicht zurück generic

errors: [ 
    { 
    type: "ValidationError", // or an int value from an Enum 
    message: "First name is required", 
    }, 
    { 
    type: "DBError", 
    message: "Connection not found" // you might want to say something more generic here, but at the same time if you don't treat it at all it will bubble up as a 500 internal server error 
    } 
] 

Nun sind beide natürlich möglicherweise nicht zur gleichen Zeit passieren, aber nach wie vor, möchten Sie Ihre API so allgemein wie möglich, Ihre Kunden von ersparen Bündeln „if“ s in ihrem Code.