Structure de réponse Api avec définitions de colonnes configurables

Question

Je construis une application pour un système de demande d'étudiants qui permet à plusieurs organisations de fournir un formulaire de demande en ligne à ses étudiants pour postuler à des cours. Pour chaque application, il aura ID, StudentName, CourseName. Cependant, certaines universités exigent SecondaryExamMark et certaines exigent le nom de référence et le numéro de référence.

Je fais un appel API (/ application/liste? Pageno = 1 & rowsPerPage = 20 & OrgID = 1) et renvoie toutes les données d'application avec des informations communes ainsi que les exigences supplémentaires en fonction de l'ID d'organisation fourni

J'ai défini un modèle d'application qui inclut toutes les propriétés communes plus un sous-ensemble de propriétés toutes les organisations demandées et les stocke dans une seule table de base de données avec quelques champs nullables pour différentes organisations.

En termes de structure de réponse Api, lequel des éléments suivants est le plus approprié?

{ 
    ID: 1, 
    StudentName: 'A B', 
    CourseName: 'B C', 
    ReferenceName: null, 
    ReferenceContact: null, 
    SecondarySchoolMark: '80' 
} 

OU

{ 
    headers: [ 
     { 
      Title: "ID", 
      Type: "text" 
     }, 
     { 
      Title: "StudentName", 
      Type: "text" 
     }, 
     { 
      Title: "CourseName", 
      Type: "text" 
     }, 
     { 
      Title: "SecondarySchoolMark", 
      Type: "text" 
     } 
    ], 
    application: [ 
     { 
      Title: "ID", 
      Value: "12345" 
     }, 
     { 
      Title: "StudentName", 
      Value: "A B" 
     }, 
     { 
      Title: "CourseName", 
      Value: 'B C' 
     } 
     { 
      Title: 'SecondarySchoolMark', 
      Value: '80' 
     } 
    ] 
} 

La première approche semble être une structure générale Api qui renvoie un objet qui décrit une application. Cependant, la deuxième approche permet à l'API de décider quelles colonnes doivent être rendues, et l'interface utilisateur n'a qu'à traiter la réponse comme des champs d'affichage. IMO, je préférerais la première approche parce que pour rendre l'API intégrable avec d'autres clients, l'API devrait fournir des réponses basées sur les ressources. Et afficher ou masquer les colonnes (que ce soit basé sur un autre appel api/getdisplaycolumns OrgID = 1 ou tout simplement traiter des colonnes null comme caché est la responsabilité de l'assurance-chômage?)

Modifier 1: retour pas nécessairement les propriétés nulles de l'approche d'un comme le sérialiseur Json permet d'ignorer les propriétés nulles)

Answer 1

Je suis d'accord, le fait de se contenter d'un modèle (ressource) qui a quelques propriétés nullables que le client peut ignorer sonne comme un design plus robuste (propriétés fortement typées!) que de désérialiser le deuxième modèle est dans un dictionnaire de sortes et de travailler avec cela.