Standard ouvert OAC

Une spécification JSON neutre pour les données d'établissement — restaurants comme commerces. Un seul point d'accès renvoie tout ce dont vous avez besoin pour afficher, router ou réserver.

Exemple rapide

curl https://www.openalacarte.com/api/standard/v1/restaurants/<slug>

Sans authentification. Mis en cache en périphérie pendant 5 minutes. CORS ouvert — appelez-le depuis un navigateur.

Ce que contient la réponse

restaurant.*

Identité, contact, devise, adresse avec lat/lng, horaires d'ouverture par jour, ce qu'ils acceptent (réservations / livraison / retrait).

menu.sections[].items[]

Le menu actif principal de l'établissement (`sortOrder` le plus bas) — nom, description, prix, devise, allergènes, image — groupé par section. Un établissement disposant de plusieurs menus n'en publie qu'un ; les charges utiles multi-menus sont prévues pour la v2.

spec + fetched

Enveloppe versionnée (`openalacarte.standard/v1`) + horodatage ISO pour que les caches en aval sachent ce qu'ils ont.

Identifiants stables

Le `slug` de l'établissement est l'identifiant canonique. Les slugs sont attribués à la création et ne sont jamais réécrits : un slug que vous stockez reste donc valide.

restaurant.venueType

Soit `restaurant`, soit `shop`, dans chaque réponse. Branchez-vous sur ce champ — pas sur les autres champs qui se trouvent être vides.

Restaurants et commerces

Les boulangeries, boucheries, épiceries fines, primeurs et cavistes forment une classe d'établissement distincte sur OpenALaCarte, et ce point d'accès les sert également :

Les deux classes répondent sur le même chemin /v1/restaurants/ et arrivent sous la même clé de premier niveau restaurant. Les deux sont figés — v1 promet que le code écrit contre lui continue de fonctionner, et déplacer les commerces casserait précisément cela.
restaurant.venueType est le discriminant. Il est présent dans chaque réponse, vous pouvez donc le lire sans valeur de repli.
Un commerce renvoie toujours acceptsReservations: false. Les commerces ne prennent aucune réservation, à aucun palier : c'est donc un fait sur la classe d'établissement — jamais un restaurant qui aurait désactivé les réservations.
Le champ cuisine d'un commerce porte sa catégorie de vente (boulangerie, boucherie, primeur), et son menu est son catalogue de produits, dans la même forme sections-et-articles.
Un commerce qui vend sur des emplacements de marché plutôt qu'à une adresse fixe publie address: null et un tableau hours vide. Sa ligne d'adresse est un dépôt et ses horaires de vente relèvent d'une tournée : ni l'un ni l'autre ne décrit une porte où un client peut se présenter.

Versionnage

SemVer au niveau de l'URL. Les ajouts v1.* sont rétrocompatibles (nouveaux champs, jamais supprimés/renommés). Les changements incompatibles passent à /v2/ avec un chevauchement de 12 mois.

Les dépréciations sont annoncées dans le journal des modifications développeur de cette page + via l'en-tête de réponse Deprecation.

Où ces données apparaissent également

Les mêmes informations sur les établissements sont publiées sous plusieurs formes. Pour être précis, il s'agit de représentations parallèles et non de consommateurs de ce point de terminaison :

Notre JSON-LD pour Google Maps Reserve et Apple Business Connect — les mêmes informations, générées depuis la base de données plutôt que récupérées via ce flux.
Les widgets intégrés (/restaurants/[slug]) — la même charge utile, rendue en HTML.
(Futur) intégrateurs tiers — DoorDash, Uber Eats, Tock — lorsqu'ils veulent des données OAC canoniques

Vous construisez par-dessus ? Écrivez à devs@openalacarte.com et nous vous référencerons ici.

Pourquoi un standard « ouvert » ?

Parce que la spécification est documentée + versionnée + stable. Nous nous engageons à ne pas la casser. Si vous écrivez du code contre /v1/, ce code continue de fonctionner — même si OAC change de cap, même si nous sommes rachetés.