Plusieurs option paramètres de chaîne de requête API REST OBTENIR

Je suis à l'aide de l'api web 2 pour mettre en œuvre un service restful. Après avoir fait quelques recherches sur les meilleures pratiques, tout le monde semble qu'ils sont d'avoir des opinions différentes sur la façon de faire les suivants. J'ai un

public HttpResponseMessage Get(string crewId, string shiftDate, int offset = 1, int limit = 10)

Cette méthode renvoie une liste. Il y a plusieurs façons d'obtenir les données à partir de cette méthode.

  • Obtenir par crewId seulement
  • Obtenir par shiftDate seulement

ou

  • Obtenir par crewId et shiftDate

Avez-vous (1) Marque de la crewId et shiftDate comme option?

public HttpResponseMessage Get(string crewId = null, string shiftDate = null, int offset = 1, int limit = 10)

et puis avez des tas de if pour vérifier ce qui est comblée et ce n'est pas remplie pour être en mesure de faire des gestes

if(crewId != null && shiftDate == null){
  //Get by crewId
}else if(crewId == null && shiftDate != null){
  //Get By shiftDate
}else if(crewId != null && shiftDate != null){
  //Get By crewId and shiftDate
}

Pour moi, cela semble fou à faire, surtout si vous avez de nombreux paramètres vous avez trop de "si" déclarations dans votre code.

Avez-vous (2) Ont ensemble différent de?

public HttpResponseMessage GetByCrewId(string crewId, int offset = 1, int limit = 10)
public HttpResponseMessage GetByShiftDate(string shiftDate, int offset = 1, int limit = 10)
public HttpResponseMessage GetByCrewIdShiftDate(string crewId, string shiftDate, int offset = 1, int limit = 10)

et ensuite, vous avez votre URI feuille de Route pour la méthode

  • .../api/GetByCrewId?crewId=1234
  • .../api/GetByShiftDate?shiftDate=1111-11-11
  • .../api/GetByCrewIdShiftDate?crewId=1234&shiftDate=1111-11-11

est l'option 2 reposante?

Ou est-il une meilleure options (3).

Les deux options ci-dessus va travailler tout en faisant que je suis sur les meilleures pratiques suivantes en matière de REPOS. Semble juste comme je suis en manque de quelque chose et j'espère que vous pouvez me mettre dans la bonne direction.

OriginalL'auteur Nick Manojlovic | 2016-01-19

  1. 5

    Vous ne voulez pas l'option (2) - pour être paisible vous voulez des noms dans votre URL.

    Si vous voulez que votre URL est:

    /api/items/?crewId=1234&shiftDate=1111-11-11

    (Je ne peux pas savoir ce que vos Articles sont, basée sur le 'Crew' et 'Shift' les noms des paramètres. Ce qui a un Équipage et un Changement de date?? Des excursions de pêche?? Si oui, l'url serait mieux comme /api/pêche-voyages/?crewId=....&shiftDate=...

    Comme pour le contrôleur, j'irais pour quelque chose comme:

    public HttpResponseMessage Get(string crewId = null, string shiftDate = null, int offset = 1, int limit = 10) {

    return dataSource.Where(x=> (x.CrewId == crewId || crewId == null)
            && (x.ShiftDate == shiftDate || shiftDate == null));
}
    Merci pour la réponse @Anthony - La seule chose que je crois que vous auriez encore d'avoir si les déclarations parce que je ne veux pas même pour interroger la base de données pour crewId de shiftDate si on est nul Parce que Si je fais ce que vous avez ci-dessus, il va chercher où le shiftDate ou crewId est nulle et retour mauvais jeu de données. Mais dans l'ensemble le concept de l'OBTENIR est même ce que j'ai pour l'instant que d'avoir un moment difficile de l'accepter.
    La méthode de contrôleur fait ce que vous dites. Prendre la première ligne par exemple: x.CrewId == crewId || crewId == null . Si crewId est null, la déclaration résout vrai et que le dossier serait autorisé à tester la shiftDate. Si c'est null, alors la shiftDate déclaration permettrait de résoudre le vrai et le dossier serait renvoyé.
    Je vois jamais l'esprit - mon erreur j'ai jeté un coup d'oeil très rapide au cours de la linq déclaration, j'ai pensé que vous aviez x.CrewId == null. Vous avez absolument raison.
    Facile à manquer avec juste un coup d'œil

    OriginalL'auteur Anthony

  2. 2

    J'ai fait quelque chose comme ça avant. Puisque vous pouvez utiliser l'un ou l'autre ou les deux, je voudrais utiliser les paramètres facultatifs:

    public HttpResponseMessage Get(string crewId = null, string shiftDate = null, int offset = 1, int limit = 10)

    Alors construire votre requête. Par exemple, quelque chose comme ceci:

    var query = "";
if (!String.IsNullOrEmpty(crewId)) {
  query += $"crewId='{crewId}'";
}
if (!String.IsNullOrEmpty(shiftDate)) {
  if (query.Length > 0) query += " AND ";
  query += $"shiftDate='{shiftDate}'";
}
if (query.Length == 0) {
  //neither crewId or shiftDate were given
  //return some kind of error
}
    Merci Gabriel Luci pour Répondre. C'est ce que j'ai actuellement est d'OBTENIR avec des paramètres optionnels, mais juste avoir un moment difficile de l'emballage de ma tête autour de ce que je devrais avoir si des instructions pour chaque éventuellement des résultats. Si j'avais n paramètres, j'aurais n possibilités qui est tout simplement fou, mais probablement de la manière que je ne peux pas d'accord avec moi-même 🙂
    Il y aura probablement une certaine logique qui est commun, peu importe qui les identifiants sont utilisés pour faire de la recherche (par exemple, vous cherchez toujours "activé" enregistrements, ou quelque chose comme ça). Afin de dupliquer cette logique en plusieurs contrôleurs est probablement pas une bonne idée.

    OriginalL'auteur Gabriel Luci

  3. 2

    L'examen Meilleures Pratiques: la Compréhension RESTE en-Têtes et les Paramètres il affirme que l'utilisation du paramètre de requête indique que c'est facultatif. Si vous pouvez faire une seule valeur, et les autres en option, il peut aider à préciser l'URI.

    /api/fishing-trips/crew/{crewid}?shiftdate=1111-11-11

    En fin de compte, si vos articles sont tous facultatifs que l'utilisation des "?" est probablement le meilleur itinéraire. De plus amples informations sur les types de paramètres sont disponibles à RFC 6570.

    Noter que votre choix peut avoir un impact sur toutes les files d'attente que vous choisissez d'utiliser et le chemin de style paramètre d'expansion peut faire le plus de sens. Plus d'informations également à La compréhension RESTE Paramètres.

    Enfin vous pouvez créer des paramètres de recherche puis, si vous trouvez que vos utilisateurs sont souvent demander la même recherche, vous pouvez l'emballer dans un seul RESTE du chemin.

    Par exemple,

    /api/fishing-trips/search?crew=1234
/api/fishing-trips/search?shiftDate=1111-11-11
/api/fishing-trips/search?crew=1234&shiftDate=1111-11-11

    Vous pouvez également fournir une simplification avec des paramètres optionnels, par exemple,

    /api/fishing-trips/today
/api/fishing-trips/today?crew=1234
/api/fishing-trips/crew/1234/today

    Ces derniers exemples sont subjectives de ma recherche, mais des informations supplémentaires sont disponibles à Les meilleures Pratiques pour une Pragmatique de l'API Rest et Reposant URL de conception pour la recherche.

    OriginalL'auteur McArthey

  4. 1

    Considérant que je suis sur le point de mettre en œuvre cette moi-même, je dirai qu'il devrait y avoir une seule GET méthode d'action avec de multiples paramètres facultatifs.

    Pourquoi? Parce que vous ne devriez pas vous inquiéter à propos de cette interrogation logique dans l'API REST de la couche. Après tout, vous êtes effectivement la création d'un AND discrimination clause avec plusieurs paramètres (c'est à dire CrewId = 1 AND ShiftDate = 2016-01-01). Et si vous ne fournissez pas les paramètres, retour tous articles.

    Je vais passer mes paramètres tout le chemin à travers à une procédure stockée SQL qui a des valeurs par défaut spécifié et renvoie les résultats en fonction des paramètres transmis.

    Rappelez-vous que dans de nombreux égards, RESTE méthodes de carte directement à CRUD, afin de traiter votre API en tant que tel: API REST Tutoriel

    OriginalL'auteur toadflakz