Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. APIs
Code

Ang Paggawa ng Iyong Startup: Ang Pagdidisenyo ng isang RESTful na API

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Building Your Startup With PHP.
Building Your Startup: Running Multiple Domains
Building Your Startup With PHP: Bootstrap Your Home Page

Tagalog (Wikang Tagalog) translation by Anna Nelson (you can also view the original English article)

Final product image
What You'll Be Creating

Ang tutorial na ito ay bahagi ngserye tungkol sa pagbuo ng iyong startup gamit ang PHP sa Envato Tuts+. Sa seryeng ito, gagabayan ko kayo sa paglulunsad ng isang startup mula sa konsepto sa kasalukuyan gamit ang aking Meeting Planner app bilang isang makatotohanan na halimbawa.  Bawat hakbang sa kahabaan ng proseso, ibibigay ko ang open-source code ng aking Meeting Planner app bilang halimbawa kung saan maaari mong malaman ang pinagmulan. Tatalakayin ko din angmga isyu tungkol sa negosyo kung meron tayong madaanan.

Bakit Kailangang Gumawa ng API para sa Iyong Startup?

Ang pangunahing dahilan kung bakit ako maglalagay ng API sa Meeting Planner ngayon ay upang makalikha ng pundasyon sa paggawa ng iOS mobile application. Ang mobile app ay gagamit ng API para makarehistro at maka-log in ng mga user at pagkatapos pahintulutan ang mga ito na makapag-iskedyul ng pagtitipon.

Ang mga API ay mayroon din na sekundaryong epekto upang ikaw ay matulungang makapag-isip muli at makapaghanda nang mas mainam para sa lahat ng kowd na iyong sinulat. Tiyak na may mga lugar sa loob ng kowd ng Meeting Planner na naging kumplikado. Ngayon, gagawin ko itong mas simple muli para sa mga mobile app upang makopya ang mga feature na nasa itaas ng fray.

Maaari din na magkaroon ng ibang dahilan ang paggawa ng API sa hinaharap. Halimbawa, gusto kong pahabain ang mga uri ng pagtitipon at kaganapan na maaaring maiskedyul sa Meeting Planner ng mga third-party developers—na magbibigay pahintulot sa kanila na mangolekta at magbahagi ng karagdagang datos sa proseso. 

Bilang paalala, ang lahat ng mga code para sa Meeting Planner ay nakasulat sa Yii2 Framework para sa PHP.  Kung gusto mong matuto nang iba pa tungkol sa Yii2, tingnan ang aming parallel series Programming Sa Yii2.

Bago ako tumungo sa API kowd, nais kong hikayatin kayong subukan na magtakda ng inyong unang pagtitipon upang malaman ninyo ang aking sinasabi.

Kung mayroon kayong mga katanungan tungkol sa tutoryal o aplikasyon nito, ako ay sumasagot sa talakayan sa ibaba, at maaari din kayong makipag-ugnayan sa akin sa @lookahead_io sa Twitter. Ako ay laging bukas para sa mga bagong tampok na ideya para sa Meeting Planner at pati na rin sa mga mungkahi para sa mga susunod na episode ng mga serye.

Ang Pagdidisenyo ng Iyong API

Nang ako ay naghahanda sa paggawa ng API, mayroong mga iba’t-ibang konsepto na kailangan kong maintindihan. Tinalakay ko ang ilan sa mga ito sa Programming sa Pamamagitan ng Yii2: Ang Paggawa ng isang RESTful na API (Envato Tuts+)

Una, kinailangan kong lumikha ng endpoint para sa API kung saan papasok ang lahat ng mga tawag mula sa mga mobile app. Nagpasya akong gumamit ng isang independent na third tree sa Yii Advanced Application framework, e.g. https://api.meetingplanner.io sa halip na https://meetingplanner.io/api/. Ito ay nagbibigay ng maayos na paghihiwalay ng API kowd mula sa iba pang mga serbisyo.

Ikalawa, kinailangan kong magdisenyo ng seguridad sa API. Sa tutoryal ngayon, ipapakita ko sa inyo ang simple na alpha security na aming ginagamit, ngunit ito ay aming pagtitibayin sa paglipas ng panahon, at maaari akong sumulat tungkol dito sa hinaharap. Mayroong aspeto sa seguridad kung paano namin ginagamit at pinapadala ang mga API key at hiling, ngunit mahalaga din na tiyak na ipinapatupad ng API ang aplikasyon ng mga protocol sa seguridad. Halimbawa, ang isang user ay hindi maaaring humiling sa mga kalahok ng pagtitipon kung hindi siya ang nag-organisa ng pagtitipon o hindi siya isa sa mga kalahok.

Ikatlo, nais kong maghanda ng API kowd para sa mga bersyon. Halimbawa, ang lumang iOS application na hindi pa nababago ay maaaring gumamit ng API v1.0, habang ang mas bagong update ay maaaring gumamit ng API v2.0. Ang Yii ay nagbibigay ng mga paraan sa paggawa nito, ngunit hindi ko pa ipinapatupad ang mga ito sa kasalukuyang disenyo.

Ikaapat, hangga’t maaari nais kong sumunod sa pamantayan ng REST. Iyan ay sinimulan ko ng gawin ngunit ito ay nangangailangan pa ng mas maraming pananaliksik upang ganap na maipatupad.

At ang panghuli, sa ngayon, kailangan kong alamin ang lawak ng functionality na maibibigay ng API. Sa simula, para sa pag-unlad ng mobile application, ako ay nag-pokus sa paglikha ng read-only functionality. Ang tutoryal ngayon at ang kowd ay nakatuon sa aplikasyon ng read-only functionality, i.e. pagpapakita sa akin ng pagtitipon ng isang user. Ngunit kabilang din dito ang pagrerehistro ng mga user. Sa hinaharap, kami ay maglalagay ng mas maraming mga write function tulad ng paglilikha ng pagtitipon, paglalagay ng kalahok, paglalagay ng lugar ng pagtitipon, at pag-aayos ng imbitasyon, at iba pa.

Kaya ituring ang tutoryal na ito na unang hakbang tungo sa isang matatag, at kumpletong serbisyo ng API para sa ating application.

Ang Paggawa ng API

Ang Paglikha ng API Service Tree

Building Your Startup - the API tree

Ang Meeting Planner ay gumagamit ng Yii Advanced Application framework, na kinabibilangan ng isang front-end tree para sa application at isang back-end tree para sa administratibong bahagi, at kami ay gagawa ng third tree para sa API.

Inilarawan ko kung paano ito ginawa sa Programming sa Pamamagitan ng Yii2: Ang Paggawa ng isang RESTful na API (Envato Tuts+)

Una, kinopya ko ang back-end tree at lahat ng may kaugnayan sa environment settings:

At naglagay ako ng @api alias sa /common/config/bootstrap.php:

Sunod, magsisimula kaming lumikha ng core functionality.

Ang Pagtitibay ng API

Ako ay lumikha ng ilan sa mga pangunahing seguridad habang ginagawa namin at sinusubukan ang iOS application. Ito ay aking pagtitibayin sa hinaharap.

Ang lahat ng mga API call ay dapat may isang app_id at app_secret. Ito ay ipapadala sa anyo ng HTTPS. Subalit, walang garantiya na ito ay aming mapapangalagaan, kaya kami ay nagdisenyo ng application na tutulong upang ang mga keys na ito ay hindi matuklasan. 

Sa sandaling ito, pinalawak ko ang mp.ini file in /var/secure upang isama ang mga ito:

Pagkatapos, ako ay lumikha ng isang Service.php model upang mapangasiwaan ang beripikasyon ng mga key na ito. Habang pinagtitibay namin ito, ako ay kinakailangan lamang magbago ng isang piraso ng kowd.

Sunod, ako ay lumikha ng beforeAction sa lahat ng mga API controller upang magamit muli ang paraan na nasa itaas:

Ang mga pangunahing limitasyon dito ay ang pagpapadala ng mga security key sa bawat call at walang lagda ang mga query parameter. Ang pagpapadala nito sa pamamagitan ng HTTPS ay nakakatulong, ngunit hindi ito lubos na ligtas. Ito ay pagtitibayin ko sa hinaharap.

Ang Rehistrasyon at Login

Ang dalawang API calls lamang na lubos na umaasa sa mga API key ay ang rehistrasyon at login. Ang mga mobile user ay maaaring magrehistro sa pamamagitan ng OAuth at maaaring ipadala sa atin ang kanilang OAuth service tokens, o kaya maaari nilang ibigay sa atin ang kanilang email address.

Sa oras na ito ay matanggap, ang bawat user ay bibigyan ng isang natatanging token, at ang token na ito ay titiyakin ang mga API call ng user sa hinaharap.

Mayroon pa akong kailangang gawin upang mapabuti ang seguridad nito, ngunit hindi ko matatalakay ito ngayon.

Narito ang paunang kowd para makapagrehistro ang isang user gamit ang API at makalikha ng isang token:

Ang UserToken ay isang natatanging 40-numero na random string, na lalong mas mahirap hulaan kaysa paniwalaan na ang Amerika ay hihirangin si Donald Trump bilang kanilang pinuno.

Ang Meeting Controller

Ngayon, tingnan natin ang mga calls para sa bawat lugar ng API, na humihiling ng impormasyon tungkol sa pagtitipon. Narito ang unang bahagi ng /api/controllers/MeetingController.php:

Mapapansin sa itaas kung paano ang bawat kilos ay nagpapatunay na ang mga token ay tama.

Pagkatapos, ang bawat API call para sa mga Pagtitipon ay binalangkas na magkakahawig, tulad ng ipinapakita sa ibaba (purihin ang aking pagtatangka at disiplina):

Sa oras na ito, ang bawat call ay kinabibilangan ng $app_id, ng $app_secret at ng $token para sa mga nakalog-in na user. Ito ay aking babaguhin para sa seguridad sa hinaharap. Ito ay ligtas, ngunit hindi ito subok na ligtas.

Tingnan natin ang actionList, na naglilista ng filtering ng pagtitipon ng isang user gamit ang $status argument upang masala ang mga ito.

Sa huli, ang API ay maaaring limitahan ang bilang ng mga request ng pagtitipon sa bawat status, i.e. ipakita sa akin ang mga 15 bagong pagtitipon sa planning mode ng isang user. 

Ang lahat ng paraan ng Pagtitipon ay nilikha batay sa MeetingAPI model. Narito ang kowd para sa meetinglist() method:

Una, ang paraan na ito ay magpapatunay na ang token ay pagmamay-ari ng user:

Narito ang kowd para sa UserToken::lookup():

Pagkatapos, sinusuri namin ang filter para sa $status at kinukuha ang $timezone ng user:

At sa huli, kami ay gumagawa ng listahan ng mga pagtitipon ng user at ito ay mano-manong binabago sa iba’t-ibang mga bagay:

Habang mayroong mas madaling paraan para balangkasin ang resulta ng database upang maibalik sa API, ang pagbabago ng pinaka-komplikadong table, ang Meeting, nang mano-mano ay nagpapahintulot sa akin na kontrolin ang mga resulta ng API na ibibigay sa mga programmer. Ito ay isang pagkakataon sa akin para mapabuti at gawing simple ang API mula sa orihinal na kowd at database properties.

Halimbawa, may kowd na kailangan ang Meeting Planner upang makalikha ng mga sub-heading sa interface ng user na hindi nakalagay sa database. Sa halip na asahan ang iOS application na kopyahin ang komplikadong kowd, kami ay lumilikha na lamang ng sub-heading at ito ay ibinabalik sa resulta ng mga API.

Ang Paggawa ng API Calls

Narito ang unang paraan upang gumawa at sumubok ng mga API call. Halimbawa, kung gawin ko ang sumusunod na URL call: 

Iyon ay gagana. Ngunit, upang ito ay subukan at paganahin, gumagamit ako ng Postmanng Chrome app extension, na tunay na kapaki-pakinabang.

Narito kung paano gawin ang API call sa pamamagitan ng Postman UX:

Building Your Startup - Postman API Requests

At narito ang resulta:

Building Your Startup - Postman API Results

Iyan ay isang madaling paraan upang tingnan ang unang resulta ng development server na nagpapakita ng lahat ng aking pagtitipon:

Iyan lamang sa ngayon. Maaari niyong tingnan ang paglabas ng API tree at makita ang iba pang mga paraan. Habang pinagtitibay ko ang seguridad at pinagbubuti ang functionality ng API, susubukan kong sumulat pa ng marami tungkol dito.

Ang Pagtingin sa Hinaharap

Nawa kayo ay natuwa sa tutoryal ngayon. Malinaw naman na ang API ay lalago at magbabago habang  ang mobile development ay nagpapatuloy. Gaya ng nabanggit ko kanina, pagtitibayin at palalawakin ko ang functionality.

Muli, kung hindi ka pa nakakagawa, halina’t magtakda ng iyong unang pagtitipon gamit ang Meeting Planner. Ngayon na!

Maaari din kayong makipag-ugnayan sa akin sa @lookahead_io. Ako ay laging bukas sa bagong mga tampok na ideya at mga paksa sa mga susunod na tutoryal. O subukan ang aming helpdesk at magbukas ng isang bug report o feature request ticket. 

Manatiling nakatutok sa lahat ng ito at sa iba pang mga darating na tutoryal sa pamamagitan ng panonood ng Building Your Startup With PHP series. 

Related Links

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.