REST, GraphQL of iets anders?

Meestal HTTP JSON, omdat de app en de site dat al spreken. GraphQL als de clients het vragen en de winst opweegt tegen de complexiteit. Dat kiezen we samen, niet uit gewoonte.

Krijg ik documentatie?

Ja. Endpoints, auth, foutcodes en een voorbeeldrequest horen bij de oplevering. Zonder docs is de API voor ons klaar, voor jouw team niet.

Kunnen jullie tegen een bestaand systeem praten?

Ja, als dat systeem een contract heeft of we er een mogen omheen bouwen. Zonder API aan de overkant zeggen we het risico, hetzelfde als bij automatisering tegenover kale HTML.

Wat als de app en de site uit elkaar lopen?

Dan is de API de bron. Versionering of een flag spreken we af voordat we een veld weghalen. Weekboodschappen houdt web en app op dezelfde records. Dat is het punt van dit werk.

Een API waar je site, app en jobs dezelfde data zien.

Voor teams waarvan de app, de site en een job dezelfde records moeten lezen en schrijven. We schrijven HTTP-API's met auth, limieten en fouten die een developer kan lezen. Documentatie hoort bij de oplevering.

Vraag een API-offerte Zie welke vorm past

Een API is nuttig als twee schermen op dezelfde waarheid moeten leunen. Weekboodschappen heeft een API op Netlify zodat de Expo-app het weekplan en de lijst haalt. StepQuests deelt discovery, booking en admin op dezelfde webstack. We zetten contracten op papier: welke velden heilig zijn, wie mag aanroepen, wat er gebeurt als het misgaat.

Welke systemen praten met elkaar, welke velden heilig zijn, en wie de API mag aanroepen.

Werk dat live staat

Weekboodschappen.nl draait marketing en API op Netlify. De app praat daarmee voor account, plan en lijst. StepQuests.com bundelt booking en admin op dezelfde Next.js-app. We publiceren hier geen request-volumes. Wat je ziet is het product: één bron voor web en app.

Wat je krijgt

HTTP-endpoints, authenticatie, rate limits waar dat nodig is, fouten met een code en een zin, en docs bij de oplevering. Schema-wijzigingen in migrations. Geheimen in de omgeving, niet in de repo.

Hoe we starten

Teken op welke systemen praten, welke velden heilig zijn, en wie mag aanroepen. Eerste slice: één flow die web of app al kan gebruiken. Daarna de rest in sprints. Breaking changes zeggen we voordat we ze uitrollen.

Wanneer dit past

Dit past als meer dan één client dezelfde data nodig heeft, of als een partner moet inprikken. Een losse marketing site zonder app kan op web. Interne schermen zonder publieke API staan bij maatwerk. De software-fit quiz helpt als je de vorm nog kiest.

Klaar om te vertellen wat je nodig hebt?

Schets welke systemen moeten praten. We reageren met een contract-voorstel en een prijsindicatie. Vijf vragen in de quiz als je nog kiest tussen API, app of web.

Vraag een API-offerte Zie welke vorm past

Vragen over dit werk

REST, GraphQL of iets anders?: Meestal HTTP JSON, omdat de app en de site dat al spreken. GraphQL als de clients het vragen en de winst opweegt tegen de complexiteit. Dat kiezen we samen, niet uit gewoonte.
Krijg ik documentatie?: Ja. Endpoints, auth, foutcodes en een voorbeeldrequest horen bij de oplevering. Zonder docs is de API voor ons klaar, voor jouw team niet.
Kunnen jullie tegen een bestaand systeem praten?: Ja, als dat systeem een contract heeft of we er een mogen omheen bouwen. Zonder API aan de overkant zeggen we het risico, hetzelfde als bij automatisering tegenover kale HTML.
Wat als de app en de site uit elkaar lopen?: Dan is de API de bron. Versionering of een flag spreken we af voordat we een veld weghalen. Weekboodschappen houdt web en app op dezelfde records. Dat is het punt van dit werk.

Vraag een API-offerte