Calculateur d'alcool de mariage

Un effectif qui n'est pas un entier positif échoue avec invalid_input, si bien qu'une liste RSVP vide ne peut pas inventer une commande. La même fonction parse pure alimente l'exécuteur gratuit du navigateur et l'API prépayée, à $0.002 par requête réussie, afin qu'une application de planification et une note d'achat imprimée s'accordent toujours sur le nombre de bouteilles à acheter.

Comment invités, heures et mix deviennent des bouteilles

La pratique habituelle du traiteur part d'une consommation par invité et par heure, que ce calculateur utilise comme drinks_per_hour sauf si vous le remplacez pour un public plus ou moins buveur. Multipliez un effectif entier positif par les heures de l'événement et par drinks_per_hour pour obtenir total_drinks, puis répartissez ce pool avec un mix de beer_pct, wine_pct et liquor_pct qui doit totaliser cent.

Contrat d'entrée, forme de la réponse et comportement d'erreur

Des heures non positives, des pourcentages hors de zéro à cent et un mix qui ne totalise pas cent échouent de la même façon. Les chaînes formula et method plus un message anglais d'une ligne servent de copie. Exemple : cent invités, cinq heures, mix trente / cinquante / vingt donnent cinq cents consommations, cent cinquante bouteilles de bière, cinquante de vin et sept de spiritueux. Une validation en échec ne consomme pas le solde prépayé. Envoyez par POST un corps JSON avec un entier positif obligatoire guests (alias guest_count, people, headcount, party_size, n, rsvp), un hours fini positif obligatoire (alias event_hours, duration, duration_hours, reception_hours) et trois pourcentages de mix beer_pct, wine_pct et liquor_pct (alias beer, wine, liquor et les noms percent et share correspondants). Chaque pourcentage est un nombre fini de zéro à cent inclus, et les trois doivent totaliser cent à un centième près ; une réception bière et vin seulement envoie liquor_pct zéro. L'option drinks_per_hour (alias dph, drinks, rate, drinks_per_guest_per_hour) vaut un si elle est omise, le rythme habituel du bar ouvert. Un effectif manquant, nul, négatif, fractionnaire ou qui n'est pas un entier positif échoue avec invalid_input en nommant guests et n'est pas facturé. En cas de succès le corps répète les entrées, renvoie total_drinks comme guests fois hours fois drinks_per_hour, les consommations par catégorie après le mix, et beer_bottles, wine_bottles, liquor_bottles et total_bottles après plafond. Les constantes wine_servings_per_bottle cinq, liquor_servings_per_bottle seize et beer_servings_per_bottle un permettent d'expliquer la conversion dans l'interface. Gardez les requêtes petites, figez les décomptes de bouteilles dans les tests et traitez les pourcentages comme un mix qui doit totaliser cent : s'il vous faut un toast au champagne, ajoutez ces bouteilles en dehors de cet endpoint.

Où un calculateur d'alcool de mariage gagne sa place

Traiteurs et barmans mobiles peuvent exposer guests, hours et trois champs de mix, appeler cet endpoint parse et remplir un bon de commande avec beer_bottles, wine_bottles et liquor_bottles. Comme l'implémentation est parse pure de palier A, chaque appel réussi coûte le tarif de base publié $0.002 sans jetons de modèle ni réseau sortant. Tenez toujours compte des non-buveurs, d'un toast au champagne, des heures de danse plus assoiffées et des règles locales de service dans vos propres consignes — elles restent hors du périmètre numérique de cet endpoint, mais comptent le soir même.