Réserve carburant de vol

Les nombres invalides ou manquants échouent avec invalid_input et ne sont pas facturés.

Ce que signifient carburant d’étape, de dégagement, de réserve et de contingence

Le carburant d’étape est celui requis pour voler du départ à la destination au débit prévu : burn_rate multiplié par le temps de vol converti en heures. La réserve finale est une quantité d’attente fondée sur le temps qui doit encore se trouver dans les réservoirs à l’arrivée à destination ou au dégagement ; les règlements la citent généralement en minutes, aussi ce calculateur prend reserve_minutes et le convertit en heures avant de multiplier par le débit. Le carburant de contingence, lorsque vous fournissez contingency_percent, est une fraction du carburant d’étape qui couvre les erreurs de vent, les changements de route et de niveau ; cinq pour cent est un chiffre de planification courant, et zéro pour cent est accepté lorsque vous voulez un total brut étape plus dégagement plus réserve.

Contrat d’entrée, unités et champs de réponse

Les valeurs sont arrondies à douze décimales pour des goldens stables. Envoyez en POST un corps JSON avec trois nombres finis obligatoires : burn_rate, la consommation horaire dans toute unité cohérente telle que gallons par heure, litres par heure ou kilogrammes par heure ; flight_time, la durée prévue de l’étape ; et reserve_minutes, la réserve finale exigée exprimée en minutes. L’optionnel flight_time_unit vaut hours par défaut ou minutes lorsque l’étape est saisie ainsi. L’optionnel alternate_time est le temps de la destination au dégagement, valant zéro lorsque vous planifiez un vol sans dégagement ; alternate_time_unit vaut hours par défaut ou minutes. L’optionnel contingency_percent est un nombre de zéro à cent inclus, valant zéro par défaut. Chaque champ numérique peut arriver comme nombre JSON ou comme chaîne numérique ; les champs manquants, les chaînes vides, les valeurs non finies, les temps négatifs, un burn_rate non positif et une contingence hors de zéro à cent échouent avec invalid_input en nommant le champ et ne sont pas facturés. En cas de succès le corps renvoie les entrées nettoyées et les temps normalisés en heures, puis signale trip_fuel, alternate_fuel, reserve_fuel, contingency_fuel et total_fuel dans la même unité physique que burn_rate. endurance_hours et endurance_minutes reformulent combien de temps ce total durera au débit donné. result duplique total_fuel pour les clients qui lisent toujours un seul champ numérique. Une chaîne formula reformule l’identité à quatre termes, method vaut trip_plus_alternate_plus_reserve_plus_contingency, et message résume la pile en langage clair. Exemple : burn_rate douze, flight_time deux virgule cinq hours, reserve_minutes quarante-cinq, alternate_time zéro virgule cinq hours et contingency_percent cinq donnent un carburant d’étape de trente, un dégagement de six, une réserve de neuf, une contingence de un virgule cinq et un total de quarante-six virgule cinq.

Où une API de réserve carburant de vol trouve son utilité

Les carnets d’ingénierie qui stockent déjà le débit carburant et les temps estimés peuvent appeler une petite API parse au lieu de redériver la même arithmétique dans chaque liaison de langage. Parce que l’implémentation est parse pure de niveau A, chaque appel réussi coûte le $0.002 publié sans jetons de modèle et sans réseau sortant, et une validation échouée ne consomme pas le solde. Gardez les requêtes petites, figez total_fuel et la ventilation à quatre termes dans les tests, et vous obtenez un carburant de planification reproductible pour briefings, greffons LMS et workers en bordure sans dresser une bibliothèque d’ingénierie de performances.