Ano ang API? Gabay sa Simpleng Salita para sa App Builder
Ang API (application programming interface) ay itinakdang paraan para humingi ng datos o magpagawa ng isang bagay ang isang software sa isa pa. Nagpapadala ang app mo ng request sa napagkasunduang format — “ibigay mo ang mga booking bukas,” “singilin ang card na ito ng €20,” “i-summarize ang tekstong ito” — at ibinabalik ng kabilang sistema ang estrukturadong response. Ito ang paraan kung paano nag-uusap ang mga piyesa ng app, at kung paano ginagamit ng app mo ang mga panlabas na serbisyo gaya ng bayad, email, mapa at AI.
Bakit mahalaga ang API kapag gumagawa ka gamit ang AI
Halos bawat kapaki-pakinabang na app ay binubuo ng mga bahaging nag-uusap sa pamamagitan ng API:
- Sa loob ng app mo, tinatawag ng mga screen sa browser ang sarili mong backend API para mag-load at mag-save ng datos.
- Sa labas ng app mo, tinatawag ng backend mo ang API ng ibang kumpanya: Stripe para tumanggap ng bayad, email provider para magpadala ng resibo, AI model provider para gumawa ng teksto.
Kapag humiling ka sa AI builder ng “tumanggap ng bayad” o “magdagdag ng AI summary,” ang tunay nitong ginagawa ay pagsusulat ng code na tumatawag sa isang API. Ang pag-alam sa mga pangunahing kaalaman ay tumutulong sa iyong maunawaan kung ano ang kailangan ng AI mula sa iyo (karaniwang account sa serbisyong iyon at API key), saan maaaring magkamali ang mga bagay, at kung magkano ang magagastos.
Isang pang-araw-araw na halimbawa
Isipin ang isang restawran. Hindi ka pumapasok sa kusina para magluto. Binabasa mo ang menu, sinasabi sa waiter ang gusto mo sa paraang naiintindihan ng kusina, at ibinabalik ng waiter ang pagkain mo — o sinasabing ubos na ang ulam.
- Ang menu ay ang dokumentasyon ng API: listahan ng mga puwede mong hilingin at kung paano.
- Ang waiter ay ang API: ang iisang napagkasunduang daanan ng mga request at response.
- Ang kusina ay ang kabilang sistema: hindi mo kailangang alamin kung paano ito gumagana sa loob.
- Ang order mo ang request; ang plato ang response.
Puwedeng palitan ng kusina ang kanilang mga oven at staff nang hindi ka naaapektuhan, basta nananatili ang menu. Iyon ang tunay na halaga ng API: pinapayagan nitong magtrabaho nang magkasama ang dalawang sistema nang hindi kailangang malaman ng alinman kung paano binuo ang isa pa.
Paano gumagana ang web API request
Karamihan sa mga API na makikita mo ay web API na gumagana sa HTTP, ang parehong protocol na ginagamit ng browser mo. May ilang bahagi ang bawat request:
| Bahagi | Ano ito | Halimbawa |
|---|---|---|
| Method | Uri ng aksyon | GET (magbasa), POST (gumawa) |
| URL / endpoint | Address ng bagay na aaksyunan mo | https://api.example.com/bookings |
| Headers | Karagdagang impormasyon, kasama kung sino ka | Authorization: Bearer <your key> |
| Body | Datos na ipinapadala, para sa paggawa at pag-update | {"name": "Lena", "time": "14:00"} |
At ang bawat response ay may:
| Bahagi | Ano ito | Halimbawa |
|---|---|---|
| Status code | Numerong nagsasabi kung ano ang kinalabasan | 200 OK, 201 Created, 404 Not Found |
| Body | Datos na ibinalik, karaniwang JSON | {"id": 5001, "status": "confirmed"} |
Ang JSON (JavaScript Object Notation) ay simpleng text format ng mga pangalan at halaga sa loob ng curly braces. Ito ang karaniwang paraan ng pagpapalitan ng datos ng mga web API.
REST: ang pinakakaraniwang estilo
Ang REST ay malawakang ginagamit na kombensyon sa pagdidisenyo ng web API. Bawat uri ng bagay ay may sariling URL, at sinasabi ng karaniwang method kung ano ang gagawin mo rito. Ganito maaaring itsura ng REST API para sa booking app:
| Method | Endpoint | Ano ang ginagawa nito |
|---|---|---|
GET | /api/bookings | Ilista ang mga booking |
GET | /api/bookings/5001 | Kunin ang isang booking |
POST | /api/bookings | Gumawa ng bagong booking |
PATCH | /api/bookings/5001 | Palitan ang bahagi ng booking, gaya ng oras nito |
DELETE | /api/bookings/5001 | Kanselahin (burahin) ang booking |
Mayroon ding PUT at karaniwan nitong pinapalitan ang buong record, habang binabago lang ng PATCH ang mga field na ipinadala mo.
Mga status code na madalas mong makikita:
| Code | Ibig sabihin |
|---|---|
200 / 201 | Tagumpay / nagawa |
400 | Maling request — may mali o kulang sa ipinadala mo |
401 | Hindi naka-authenticate — walang wastong login o key |
403 | Bawal — kilala ka, pero hindi ka pinapayagang gawin ito |
404 | Hindi nahanap |
429 | Sobrang dami ng request — naabot mo ang rate limit |
500 | Nagkaroon ng error ang server |
Kapag sumira ang app mo, kadalasang ang status code ang pinakamabilis na palatandaan. Ang 401 mula sa payment provider ay karaniwang nangangahulugang nawawala o mali ang API key; ang 429 ay nangangahulugang masyado kang madalas tumawag.
Hindi lang REST ang estilo — may GraphQL at RPC-style na API rin — pero REST ang ginagamit ng karamihan sa serbisyo at mga backend na gawa sa AI.
Isang halimbawang gawa: kumpirmasyon ng booking
Kapag nagpa-book ng gupit ang customer sa salon app, maaaring magkaroon ng ilang API call sa loob ng isa o dalawang segundo:
- Ang booking page sa browser ay nagpapadala ng
POST /api/bookingsna may serbisyo, oras at detalye ng customer sa backend mo. - Titingnan ng backend mo kung bakante ang slot, ise-save ang booking sa database, at magbabalik ng
201 Created. - Tatawagin ng backend mo ang API ng email provider gamit ang lihim nitong key: “ipadala ang kumpirmasyong ito kay lena@example.com.”
- Kung may deposito, hihilingin ng backend mo sa API ng payment provider na gumawa ng checkout session at ipadadala roon ang customer.
- Mamaya, tatawagin ng payment provider ang app mo para sabihing matagumpay ang bayad. Ang reverse call na iyon ay isang webhook.
Ang unang dalawang hakbang ay sarili mong API sa pagitan ng frontend at backend. Ang mga hakbang 3–5 ay mga third-party API.
Mga terminong ipinaliwanag
| Termino | Ibig sabihin |
|---|---|
| Endpoint | Isang partikular na URL na sumasagot sa API. |
| API key | Lihim na string na nagpapakilala sa app mo sa isang serbisyo. Ituring itong password. |
| Authentication | Pagpapatunay kung sino ang tumatawag — gamit ang key, token o login. Tingnan ang ano ang authentication. |
| Rate limit | Limitasyon sa dami ng request na puwede mong gawin sa isang takdang panahon. |
| SDK | Handang code library na nagpapadali sa pagtawag sa isang partikular na API. |
| Dokumentasyon | Ang “menu”: kung anong endpoint ang umiiral, ano ang tinatanggap at ibinabalik nila. |
| Sandbox / test mode | Bersyon ng serbisyo para sa pagsubok nang walang totoong pera o totoong datos. |
| Webhook | Tawag mula sa ibang serbisyo papunta sa app mo kapag may nangyari. |
Karaniwang pagkakamali at maling akala
- Paglalagay ng lihim na key sa frontend. Anumang nasa code na tumatakbo sa browser ay makikita ng sinumang bumisita. Dapat manatili sa server ang mga lihim na key, sa environment variables o secrets.
- Pagdidikit ng key sa chat. Maaaring naka-store ang chat history. Gamitin na lang ang secrets feature ng builder mo, at palitan ang anumang key na nalantad.
- Pag-aakalang libre ang API. Maraming API ang naniningil kada request o kada yunit ng paggamit — ang AI model API ay naniningil ayon sa token. Tingnan ang pricing at magtakda ng spending limit. Tingnan ang paano gamitin ang LLM API.
- Hindi paghawak sa pagkabigo. Bumababa, natatapos sa timeout at naaabot ang limit ang mga panlabas na serbisyo. Humingi ng maayos na error message at retry.
- Pagtitiwala sa browser. Dapat mismong suriin ng sarili mong API ang mga pahintulot. Ang pagtatago ng button ay hindi pumipigil sa taong direktang tumawag sa endpoint.
- Paggamit ng live key habang sumusubok. Gamitin ang test mode key hanggang handa ka nang ilunsad.
Ano ang hihilingin sa AI builder mo
- “Aling mga panlabas na API ang ginagamit ng app na ito, at magkano ang halaga ng bawat isa?”
- “Tawagin lang ang payment API mula sa server. Basahin ang key mula sa environment variable.”
- “Ilista ang bawat endpoint ng API namin, kung ano ang ginagawa nito at sino ang pinapayagang tumawag.”
- “Suriin sa server na pagmamay-ari ng naka-log in na user ang booking bago ito i-update o burahin.”
- “Kung pumalya ang email API, i-save pa rin ang booking at i-log ang error.”
- “Gamitin muna ang test mode ng provider.”
Mga API sa Mythex
Puwedeng gawin ng Mythex ang sarili mong API — bilang bahagi ng web app, o bilang hiwalay na backend sa Node, Python (FastAPI), C# o Java na tatakbo kasabay ng frontend mo — at isusulat ang code na tatawag sa mga panlabas na serbisyo. Ilalagay mo ang kanilang key bilang project secrets sa halip na sa chat, at magagamit ito ng app mo sa preview at kapag na-publish na. May mga recipe ang docs para sa pag-integrate ng anumang API at pagbuo ng REST API backend.
Mga tanong
Ano ang API sa simpleng salita?
Ang API (application programming interface) ay itinakdang paraan para humingi ng datos o magpagawa ng bagay ang isang software sa isa pa. Nagpapadala ang app mo ng request sa napagkasunduang format, at ibinabalik ng kabilang sistema ang response — gaya ng datos ng panahon, resulta ng bayad o AI-generated na sagot.
Ano ang REST API?
Ang REST API ay karaniwang estilo ng web API kung saan ang bawat uri ng bagay (booking, customer) ay may sariling URL, at gumagamit ka ng karaniwang HTTP method — GET para magbasa, POST para gumawa, PUT o PATCH para mag-update, DELETE para magtanggal. Karaniwang ibinabalik ang datos bilang JSON.
Ano ang API key at saan ko dapat itago?
Ang API key ay lihim na string na nagpapakilala sa app mo sa isang serbisyo, at kadalasang nagpapahintulot dito na gumastos ng pera o ma-access ang datos. Itago ito sa environment variables o secrets ng project mo sa server, hindi kailanman sa code na tumatakbo sa browser at hindi sa pampublikong repository.
Ano ang pagkakaiba ng API at webhook?
Sa API, humihingi ang app mo ng bagay sa ibang serbisyo kapag gusto nito. Sa webhook, ang ibang serbisyo ang tumatawag sa app mo kapag may nangyari — halimbawa, ipinapaalam sa iyo ng payment provider na matagumpay ang isang bayad.