FT Topic 4 Part 1 2

0:01 Good day to everyone. So our lesson for today is all about the part two nung diniscuss natin last week which is focus naman tayo kay rest and consuming API. Okay. So last time na pag-aralan natin yung about sa soft focus kay XML. And for this session so we will explain what an API is identified as common API style then explain the rest and also yung kanyang principle. So paano paano yung mga resources and also paano ginagamit dito yung Jason

0:49 style? Paano din ginagamit yung HTTP method and status code including yung safe and identi potent one. to yung yung yung anotomy niya for the request and response including diyan yung part ng um part nung part ng parang sa XML meron siyang part. Meron ba dito yung error and also yung ah practices kapag tayo ay nagse-select or even soft or rest.

1:36 So balikan lang natin. So what is API? So dito muna tayo mag-focus. So dito muna natin i-establish so ano ba talaga yung API para bago tayo pumunta doon sa actual ah implementation. So define muna natin API stand for application programming interface. So yung pinaka-important diyan is yung interface. So ano ba 'yung interface? So nagbibigay ito ng ano ng pakikipag-communicate

2:23 doon sa isang application papunta doun sa ibang application or survey server. Let's say mayon kang ginawang system web application and then makikipag-communicate yan para makakukuha ka ng service or ah or data doon sa isang um service. Example is SMS notification. Okay? Siya 'yun. And then ang pinaka-important din nito katulad ni soft. So hindi natin ano, hindi natin kailangan malaman or hindi kailangan malaman ng application

3:11 kung internally ginagawa or pina-process yung kabilang system para dun sa request ng system. Parang dito kay client. Okay. So, no need ng alamin ni ah no need ng alamin ni client doon kay server kung ano ba yung gagawin niya. Okay. So ang kailangan niya lang malaman is ah ano yung mga pwede niyang request. Okay? Papaano siya dapat mag-request at anong response ang inaasahan niya. Yun lang yung kinakailangan niya. So pero in a whole process hindi niya kailangan alamin sa web API kadalasan

3:56 nangyayaring communication gamit ang HTTP. Normally yan kaya yung magiging end point niyan naka-htp. So depende na dun sa service or doon sa may sources kung ano yung mga kailangan natin. Normally naka HTTP ang ano doun ang communication natin. Okay. And then ano ba yung nakikita natin doun sa mga concept na yon? Endpoint, HTTP, method, ano pa? Request, response, status code and also yung Jason. So lahat yun is ta-tackle natin later.

4:44 So pwede nating isipin yung API agreement or contract between the two system. Normally kapag contract ang pinag-uusapan eh 'yun lang yung provided ni server or yung sources na pinagkukunan. For example dito sa may slide 'yan lang yung yan lang yung masasabi natin na um pinakaabasis para ma-access mo or bigyan ka ng access kung ano man yung contract na meron doun kay API. Okay, let's say sabihin natin na ano um sabihin natin na technical way SMS ito. Yung SMS na to ang pino-provide niya

5:30 lang is one way. Meaning to say sa system na sa system na ginagawa mo may web app ka, kailangan mo ng SMS application ay SMS process. So ang ipo-provide lang ng API yung contract under na contract is pwede kang mag-send ng um through SMS pero hindi ka pwedeng maka-receive kasi hanggang doun lang yung kayang i-provide ni um SMS based dun sa napili mo kunyari may mga packages. So sa packages na yun do naglalaman yung contract. Okay. So

6:16 pagka ano sinasabi ng API kapag kailangan ah kailangan mo ng data or function so dito ka nagre-request. So gaano ang format na uh ah what I mean is yung format na ibibigay ni API and then also yung possible na response na pwedeng ibigay ni API. Okay. Kasi hindi naman talaga direct um pinakikilaman yung ano eh yung ah pinaka-internal code or database pagdating dito sa server. Hindi naman

7:01 pinapakilaman yan nung nag-request which is yung client. Okay? Ang pinapakailaman niya lang diyan is 'yung ah ang ina-identify niya lang diyan is 'yung contract kung ano lang. Okay. So halimbawa dito meron tayong tinatawag na client, meron tayong tinatawag na API, meron tayong tinatawag na server, meron tayong tinatawag na response. Kapag sinabi nating client, siya yung nangangailangan nung data or service. Okay? Yan yung nagre-request in short. Regardless na yan kung ano yan kung anong development ang meron diyan. So tinatawag siya na client. Okay.

7:48 For example, yung web application na ginawa mo, pwede siyang tawagin na client kasi siya yung nagre-request nung nung service. Okay. Yung API naman siya naman yung bridge. Siya naman yung tumatanggap ng request according doun sa predefined rules or contract. Okay yung server dito naman is yung actual processing. Normally sa server doun din natin dine-declare or ini-indicate yung contract ng API. Hindi yan hindi yan yung contract na literal ah na uh isang

8:36 pa ano isang paper siya. Okay. Ng contract and then do naka-state lahat. Hindi siya gann. Okay, may proper format siya later on malalaman natin. Okay. And then also yung server siya yung nag pa-process kung ano man yung ah ni-request ni client based doon sa contract na nakalagay under kay API. So since nag-request ka natural may response okay ibabalik ng server through API ang result sa client. Okay? So ganun nag um ganun yung process

9:25 na na nangyayari during a um request. So the important concept for this is yung separation. Okay. So hindi kinakailangan malaman ng client kung ah papaano internally ginagawa ng server yung kanyang ah work pagdating doun sa request ng client. Okay. So let's say magbigay tayo ng ah example. Ipapakita ko sa inyo. Hanap tayo ng isang ano um API. Weather API.

10:12 Ito ba yun? Ay hindi ito yung ano yung OP mo te. O, Open Mateo. Ayan kung mapapansin niyo dito iyung open Mateo about ito sa forecast 8 kasi yung yung ibang ano eh yung ibang weather ano weather application ano siya um magla-login pa ako so huwag na ah ito na lang so ito yung forecast

10:59 ang ginagawa nito nagbibigay siya ng data depende dun sa ah need natin so pwede mo siyang i-set up Then after that, punta tayo sa baba. Ano 'yan, um, saan 'yung ganyang ano? Ito. Ito 'yung kanyang API. So, mamag-aralan natin yang ano niya, 'yung format niya. Copy ko lang and then open ako. So let's say na ano mo na siya no? Na-setup mo na siya. Ito setup mo na to lahat. Kung ano yung mga kailangan mo, um iano mo lang dito. I

11:48 ise-setup mo lang. Okay? So depende dooun sa needs mo ' ba. So ito dito pumapasok ung contract. Since ito is public walang problema. Okay. Pero titingnan natin kung ano lang yung mga kinakailangan mo. Then after that, mababago itong ano natin ah URL natin. Okay? Yung API URL natin. Ito yung sinasabi ko kanina guys na most likely HTTP ang ating request kasi imaginin mo nagre-request ka from the other service natural naka internet ang gagamitin natin. Okay. Kaya dumadaan siya sa um https or http para secured. Okay. So marami pa

12:34 y'yan. Okay. Then also pag na-setup mo na yan, ito na yung ating nire-request kasi data lang ang kailangan natin. Okay. So kung papansin ninyo hindi na yan kamukha nung dati kay soft naka XML. So ito naka-JSON file ito. Okay. So ito nire-request natin. And then dadalhin sa application. Ilalagay yan sa application. And then after that naka-Jason yan. And then meron tayong front end para dito para ma-display naman natin. Depende dun sa ano natin. Kunyari ito forecasting. So ito nasa forecasting features ka. So ganun nagwo-work yung

13:22 ano yung API. Okay. Ito na yung nagiging response niya which is yung data. Okay. So kaya ko pinakita sa inyo para magkaroon kayo ng idea. Okay? Pagdating dun sa requesting. So lahat ng um provider or services nagbibigay sila ng tinatawag na kung papansininyo niyo na tinatawag na docs or documentation. Okay? 'Yan 'yung sinasabi na contract. Okay. Kung ano lang yung ah needed natin for that service at kung ano lang yun pinoprovide na service ni ah nung specific na ano na yun na services na

14:09 yun. For example dito weather forecast API. So ito lang yung contract. Ayan integration weather model up to 16 days forecast. Okay. So yun lang hanggang d lang yung kaya niyang maibigay. So dito i-setup po lahat. Okay. Ayan may mga historical ah ensemble model, session forecast, seasonal forecast, climate change. So iba-iba yan. Okay. Ayan nakalagay diyan lahat ng lahat ng mga needled natin nakalagay. Ayan API documentation. Okay. So ito lahat 'yan. So paano natin siya i-integrate? Okay. Using aapi.

14:56 So early parameter definition. So dito mo naman siya i-state. Ito nakalagay din doon yan sa may link makikita ninyo d sa may API sa end point. Ayan ito siya. latitude longitude or temperature. Okay. So lahat 'yan mayro'n yang may basis ito. Kaya pagka ayun pagka ginamit mo 'yung API, ito 'yung magiging output niya. So depende dun sa API ah URL natin. Okay. So balik tayo dun sa slide.

15:43 Sabi nga diyan a web a web API exposes those rules over the web usually through HTTP or HTTPS. So kung analogy 'yan kung makikita niyo diyan sa may slide ito yung sinasabi ko na sa may ano sa restaurant pansin niyo ha kayo client customer okay ikaw yung nagre-request ng order tama okay punta ka ng restaurant kakain ka bago ako kumain mag-o-order ka okay pag-order m kakausapin mo doun is yung waiter. Okay, waiter. Kukunin niya lahat ng ano mo, lahat ng ah order

16:31 mo. Yun is yung tinatawag natin na request. [sumisingasing] Okay. Lahat ng order. So si API ang gagawin niya kunwari may order ka ng um kare-kare, kanin, tapos meron kang order na ah dessert kunyari lang. Leche plan favorite ko. So yung leche plan dito sa kay waiter wala naman 'yung leche plan. So do pa lang ina-identify na ni API na yung nire-request mo wala. So magbabalik siya dito kay client or

17:16 dun kay customer. Sasabihin niya na wala. So lahat ng ina-analogy ko yun mamaya makikita ninyo. So dito pa lang sinasabi niya na wala yung request mo wala yung order mo. So lahat naman ng order dadalhin na kay kitchin. Ipe-prefer na yon. Okay. So si client kung sa analogy or customer tayo naman natin alam kung paano pine-prepare 'yun eh. Basta ang binibigay sa atin is yung order natin yung luto na. Okay? So ganun din sa API. Ganun din sa request natin from other application. naman natin alam kung paano pinrovide itong data na 'to. Itong data na 'to kung saan galing 'to

18:02 kung saang databases to naka-store kung paano ito nagkaroon ng data na ganito. Manin alam yan eh. Ang alam lang natin is ah kung ano kung ano yung ni-request natin, ano yung inorder natin kay API. 'Yun lang naman yung alam natin. Pero 'yung behind n hindi natin alam. And then also si Kchain siya yung responsible para yung magprocess nung order natin. Kung sa API naman, siya naman yung responsible para magprocess nung request. And then also kapag ito nag-response si server sasabihin niya okay ready to ano na 'to? Um naka-prepare na to. Ready na for serve. Okay? So ang gagawin naman ni API hindi naman si Ken ang magbibigay non. Si API

18:47 din ang magpo-provide nung um response para ma-deliver or maibigay kay ah customer which is ganun din sa API. Si si API din ang responsible para i provide yung mga necessary na kailangan niya based doon sa contract. Okay, next API styles today. So, marami yan. Pero ang focus natin for this one is um yung rest. Okay. Beside doun sa soft na pinag-aralan natin ah those are the API style na meron. Okay.

19:36 Okay. Doon tayo sa rest. Ano ba 'yung rest? Naririnig natin 'yan eh. Okay. Pero pa ano ba 'yung pinakaadefinition ni Rest? So si rest is stand for re presentational state transfer. Okay. So kanina ang nakita natin na may iba't ibang AP style which is R, scrap, ah, QL, GR, PC. Since rest ang focus natin for today, so ngayon kailangan nating maintindihan ano ba yung ibig sabihin ng RES, API. Okay. So important distinction dito

20:21 guys. Rest is not a programming language library or protocol. It is an architectural style. Set of guidance not a strict protocol like soft. Okay. Kasi si soft kung napansin niyo last time meron siyang standard na sinusundan. Okay. Dito walang strict protocol na nangyayari. So rest is stand for representational state transfer. Ang rest siya yung nagse-set

21:08 for architectural guidelines. Okay? So kung paano natin dapat i-design ang communication between system particularly over the internet or over the web. Kapag rest ang approach natin guys. So isipin natin yung data ng system as resources. Okay. So for example, meron mayong isang clinic system. Possible na resources na diyan is what? Una, appointment ba pet client ba and services.

21:55 Then each resource can be identified through URL or URI. 'yung parang nakaganito siya. Pwede naman to sulatin. Ito nak ganito siya. Slash pointment. Meron naman yung iba. PSY ah client so on. Okay.

22:41 So instead na gumawa tayo ng is ng ah ability URL para dun sa bawat action. So ang ginagawa natin is ino-organize natin okay yung API around the resources of the system. Okay? Wala tayong uniform kumbaga ah each each resources meron tayong pinagkukunan. may identified tayo. Okay. For example, kay appointment, alam natin pagka ang API natin is for appointment, alam natin yung mga process for that. So babasahin na lang natin dun sa documentation kung ano ba yung mga intended or specific na

23:29 sources na meron kay appointment. Okay. So instead na gumawa tayo nga ng ganon. So each API ino-organize yan into a API for um resources for each um for each identified sources. Okay. Kapag rest guys. So isipin niyo ano ba yung ah resources ng system ko tapos ano yung gusto kong gawin para dun sa mga resources na yon. So for example ah meron tayong appointments

24:14 uh resources ' ba ito. So pupwede nating gustong ano doun pepwede nating gustong gawin is ganito. Kunin yung appointment 'di ba? Ah gumawa ng appointment i-update ang existing appointment or tanggalin yung appointment. Okay. So hindi kailangan gumawa ng completely different mechanism para sa bawat isa. So ginagamit natin ang standard capability ng HTTP. Okay. So paano ba nagwo-work yun? Like for example, meron nga tayong appointment na may ID na 125.

25:02 So pag yan kukunin natin yan. Sample no na mamaya makikita niyo din ong mga 'to. Get natin and then yung ID niya is 125. Okay. So the UR the URL itong URL is identified the resources which is kalimutan ko app/ appointment. /125. So ito specific appointment. At 'yung get naman, tell the server kung anong operation ang gusto nating gawin. Okay? So the possible response nito will

25:50 be naka-JSON. Naka-Jason yan katulad kanina. Okay. For example, ID tapos 125 and then client dela Cruz Pet Milo, um service, vaccination, status, confirm. For example lang naman ganun yung ano niya ganun yung laman niya. So dito po dito pumapasok yung representation. So yung sa representational state transfer so hindi pinapadala sa client ang actual PHP object database row or internal service implementation. Instead, nagbibigay ang server ng representation

26:37 of the resources current state. Commonly, ang format niya is naka-Jason dahil ang usapan ang ano natin dito is rest API. Okay. Ulitin ko lang kanina yung nakita ninyo. This one, ito is representation. Okay. Representation para dun sa resources current state. Okay. Hindi totoo naman eh. Um sa back end ito lang yung need eh. Kapag meron na tayo nito, normally tayo na yung

27:24 magma-manipulate nito dun sa web app dun sa client. Paano natin idi-display yan? Gagawa ng UI depende dun sa gamit mong language 'di ba? Okay. So yun yun. And then lang ha yung aking ano. Okay. So sa server ah resource ah ang process na ang process doon for the representation is resource in server tapos Jason representation then client. Okay, ito na yung sa response. Okay. Ulit ulit. Balikan natin non. Ito yun.

28:11 Resource server Jason representation tapos sa client. Okay. Balik na tayo doon. So important, paki-note na lang to. This is the important. Rest is not the same as Jason. Okay, ito na naman yung misconception natin. So hindi porket may end point tayo na nagre-return ng Jason ay automatically well designed restful API na yon. Jason is primarily the data representation format. Data representation format. Uulitin ko, is the architectural style

28:59 governing how resources and interaction are designed. Okay? For example nga, naka-Jason siya yung ID na 125 then status confirm. So yun Jason lang yun. Okay. Wala pang sinasabi na kung yun is restful ba ang architectural or architecture. to y representational state transfer. Ito iyung part ng term na minsan mine-memorize lang pero hindi naman talaga siya iniint. Okay? So suppose meron tayong 125 currently. Okay 'yung ating

29:47 ah gawa tayo ng ano dito. Ayan ito id tapos 125 status Tapos pending.

30:39 Okay. Okay. Ayan. Suppose meron tayong ano no sa appointment meron tayong ang genet natin is 125 una pending tapos later on later on pag nag-confirm na si ah si clinic ito magiging ah confirm na magiging confirm na yung information. Okay. The client is interacting with the

31:26 representation of the current state of that resource. So hindi natin direct binibigay sa client ang internal database implementation. The API exposes a representation that the client can understand and work with. So bakit nagma-matter yun? Rest work naturally with technology na ginagamit doon sa web. [sumisingasing] HTTP plus URL plus HTTP method plus status code plus representation. Kaya practical itong gagamitin sa maraming web and mobile application.

32:11 Okay. At magandang foundation ito because yung susunod natin na nating concept which is the resources, endp, http method, request and response, status code and Jason. So magkakaano yan magkaka magkakaalign doon under ng rest. Okay. Imagine suppose meron tayong ano um API/student/2026 0125. So anong resources ang nire-refer non? 'Di ba? A specific student resources can identified by 2026105.

33:02 So dun pa lang sa API. So na-identified na natin kung ano bang resources ang possible na magiging respond ni um ni server or yung service. Then the follow up. So pero pero ito um alam ba natin kung um paano yun baguhin or i-delete ng student? Siguro naman hindi kasi ang kailangan lang naman malaman is yung um HTTP which is yung method na get put patch and delete. Okay. So remember

33:49 guys, rest organize an API around resources. Identify those resources through URL or URI [sumisingasing] and uses standard HTTP mechanism to interact with them. Okay. So rest principle para mas differ natin siya. So sa previous slide so dinefine natin yung rest architectural style na hindi lang simple na paggamit ng HTTP or Jason. So ngayon ang question natin um ano naman yung mga guidelines na sinusunod para masabing

34:35 restful ang design ng isang API. Okay? So dito pumapasok yung restle. So dito sa slide na to guys ah meron tayong client server stateless cashable uniform interface and layer system. So hindi kailangan na kabisuduhuin lahat ng pangalan na to no guys. So mas maimport mas important dito is yung anong architectural problem ang sino-solve ng bawat principle. Okay. So doon tayo mag-focus. Number one muna yung client server. Sabi diyan sa slide, the client and the server are separate.

35:22 Each can change without affecting the each other. So first principle natin which is the client server, separation of concern between the client and server. So the client so responsible user facing side while the server is responsible for the data and business operation na in-expose through the API. Okay? Yung sample natin kanina. So react web app tapos kunyari lang no react web app yung ano niya then rest API ang gamit natin. So ang ang backend

36:10 is PHP. So ang database niya is MySQL. Kunwari lang ganun iyung kanyang architectural. And then suppose later gusto nating palitan ang React web app ng mobile application. So magiging Android application na siya. Tapos same pa rin ang rest API. So doun naman sa sa ano natin sa server which is the back end PHP and then MySQL. So hindi na sarili ah kailangan baguhin ang buong back end dahil lang nabago ang client. Nagbago yung client ' ba from from React naging mobile. Ganun din sa server side. So pupwedeng magkaroon ng

36:55 internal changes sa backend nang hindi na kinakailangan ng permission or malaman ng client ang lahat ng implementation details don sa changes. So as long as the EPA contract remains compatible, okay, so our main idea for that is that um client and server can evolve more independently. In short, wala silang pakilam sa isa't isa pagdating sa mga changes etc etc. As long as APA contract remain compatible. Okay. Next. Number two, stateless.

37:40 So stateless sabi diyan, each request carries all the information it need. The server keep no session between calls. So ito yung pinakamahalagang rest. Kapag sinabi nating stateless, each request from the client should contain the information necessarily from the server to understand and process. Request. Hindi dapat umasa ang server sa client specific session state. Ito yung ah ito yung um ito yung kumbaga meron tayong sine-set aside mula dun sa previous request. Okay? Yun yung pinaka-essence niya eh.

38:28 For example, ang sabi natin get/API/prile. Tapos authorization natin is yung meron tayong authorization doon. Then after that sa another request API/ appointment authorization meron ding authorization. So sa bawat request kasama ulit yung information ng credential needed to identify or authorize the request. Hindi ganito 'yung thinking no'no. Ah request one server tatandaan tatandaan mo muna kung sino ako. Parang ganon. Request two alam mo na kung sino ako based doun sa previous request. Hindi siya ganun no? Hindi dapat ganun ang

39:13 thinking natin. So ibig sabihin each request meron siyang ah information or credential needed to identify or authorize the request. Kasama kasi yun sa security. So pwedengpwede ring ganito. Ah ito clarification guys. Stateless does not means walang database ang server. So pepwedengpwedeng mangyari na si user appointment order product. So ang tinutukoy natin na state less yung client session between the request.

40:02 Okay? Hindi absence or persistent application data. Okay? So kailangan nating anuhin yun? Liwanagin yun. Okay. Stateless walang sine-save ang server. Okay. Number cashable. Sabi diyan, "Response can be cash to reduce load and improve performance." Okay. May API responses na hindi naman kailangan kunin at i-process from scratch every single time. Kasi kailangan na kailangan may mga technique gina. Ayun niya nga yung cash kumbaga ang essence ng letto guys kapag

40:48 nag-request ka let's say nag-request ka may endp ka na app service tapos ang client service mo bihira lang magbago ng info. Okay. So instead na paulit-ulit na i-request or kunin tapos ipa-process na naman 'yung same na information 'di ba? So certain sa dun sa dun sa certain response so ang ginagawa niya is cash when caching rules permit it para bagang ang nangyayari client request tapos can cash response available. So kapagka

41:33 um yes ire-return niya lang yung cash pero kapag wala magpa-process siya at saka magre-response yung um server. So meaning to say kapag naman kapag naman na available naman yung yung data dun sa una mong request meron kang um temporary uh memory para doon. So 'yun ang gagamitin niya. So hindi na siya paulit-ulit na magre-request doon sa server. So yung benefits ng ganon sa cashable less unnecessary processing, low server load tapos potentially faster response kasi nga may mga ah may mga response na tayo

42:20 na no need to ah process kasi meron naman ng nagre-return ng cash. So 'yun ang cashable. Pero hindi lahat ng ano ha, hindi lahat ng hindi lahat magandang i-cash no. May mga frequent frequently changes or extend sensitive data required appropriate caching rules. So hindi siya lahat. Okay. Number four is uniform interface. Pag sinabi nating uniform interface, so ito naman yung nagbibigay ng consistency sa sa way na pakikipag ano natin, pakikipag-interact natin sa resources. So ganito. Um suppose meron tayong

43:06 ganitong API design. Sabi natin is um get SL API pet tapos get/API 15 tapos API pet tapos meron tayong delete API pet 15 okay so yung design natin is predictable ang structure compare natin sa ah sa inconsistent design. Ah pakita ko nga. Wait lang pakita natin yung structure.

43:57 Ayan. Pakita tayo ng sample. [nililinis ang lalamunan] kaninang inano natin gagawin ko lang อ [nililinis ang lalamunan]

44:55 P delete ayan pag ganyan predictable ang structure natin pagdating sa AP design compare natin dito Ay dali lang ayusin ko lang nakaano ako.

45:42 SL get all pets apy SL find pet tapos sabihin natin yung ID is equ to 16 create new ah pet tapos ah remove

46:28 remove Pet ID/25. Tingnan niyo yung dalawang design which is ito. Then ito. Pag ganito yung design natin, mas predictable. Okay. Ah, predictable structure structure. Okay. Compare natin dito sa isa.

47:13 Inconsistent yung design niya. So bakit kaya ganun nangyari? So possible naman na gumana yung second design which is ito pero nawawala yung consistent resource oriented interface na in-encourage ng rest. So ang goal kasi ah kapag naintindihan ng developer ang pattern ng API, mas predictable kung paano niya i-access ang ibang resources. Okay. Parang dito alam na alam na ng developer na nagge-gets niya na yung part na yan. Okay. Gets niya na na itong part na to is more on ang AP niya is delete. Dito naman is post. Dito naman

48:00 is get. Okay? Pero pag ganito kasi like API T's get all pets. T's dito naman find pets. T's dito naman is create new. Dito naman is remove. Naiintindihan naman yan. Gumagana naman yan kaso nawawala yung consistent resource umriented interface. Okay. So yun ang isa sa portion nung ano natin um dito sa uniform interface na sinasabi resources are access in one consistent predictable way. Okay? Kasi tandaan niyo yan lalo na kapag gumagawa kayo ng public na API. So may

48:46 mga tendency na kailangan natin maging um oriented resource oriented interface pagdating don sa wino-provide natin para at least kapag ina-access na 'yan at um ina-access na 'yan at sine-setup na yan okay ng developer ng client okay ah mas predictable yung nangyayari okay predictable yung way ng API design natin kasi yung structure mo maayos. Okay? Alam niya agad. Parang ganun lang naman kasimple yun. So number five is layered system. Ang sabi diyan a client cannot tell whether it talks to the

49:34 server directly or through an intermediary sa part. Okay. So tingnan natin. So sabi natin layered system. So ito yung principle na ano eh um madaling makita sa actual production architecture. So kapag nag-request ang client, let's say ang ano ang process is from mobile application kay client, API getway tapos ah meron pa tayong ah load balancer tapos application, server t's database. Okay. Para bagang ito pakita ko sa inyo ganito lang siya kasimple

50:22 kunyari dito yung kay mobile application okay so let's say meron tayong may process dito about the ano about the ano ba yung sample natin dito mobile application. Sabihin nating m yun SMS notification. Okay. Yung application na to ah OTP sabihin nating ganon. OTP naglog ah nagano siya nag-change password siya tapos ang ang ano natin do dali lang yung aking ano yan.

51:08 yung ating kwan do yung ating process pag nag-login siya ay pag nag-forgot password siya mag magse-send ng OTP. Okay? Ung OTP na yon is ganito yung process niya. Paano paano niya makuha yun? Paano paano nag-send sa kanya yan through SMS? So ganito siya. So mobile application tapos ito yung ating API gateway. 'Yung ating API getway dito naka-state lahat nung mga dito naka-state lahat ng mga contract. Sabihin nating magre-response lang naman si server ng OTP. So yun lang yun. Yun lang nakalagay doon. So meron diyang

51:54 nakalagay diyan ah API ' ba get. Sabihin nating get ah SLAPI SL ah ano ba yung kanyang ano ah OTP OTP SL kunyari yung ID niya is 15 so yun ang magiging ano ni API tapos meron tayong may layer tayo na sabihin natin is load balancer. Si load balancer naman ang ginagawa niya siya may nagha-handle kung ilan yung request. For example, sabihin nating

52:40 madaming nagre-request. Okay? Siya yung magha-handle nung siya yung magba-balance nung request. Okay. And then pag na-balance na yung request, so pupunta na siya kay application layer yung ah application server. What I mean? Application. Ay ba yan? Application server. So ang ginagawa naman nito guys application ah server. So dito na pina-process 'yung request. Tapos meron pa tayong ah sabihin natin meron tayong pasensya na kayo wala akong ibang

53:25 um shape. Ito naman yung sa server. So ito yung ating ah sabihin natin ito yung ating mobile app. Mobile app. sa mobile app. Ito yung client natin. Siya yung nagrere-request. T's ito yung ating um API. Ayan yung ating API. ba 'yun?

54:15 Ate ano ba yan? Ayan. And then dito yung ating sabihin natin meron tayo ditong yung load balancer. Tapos dito yung ating application server. So dito na yung sa server no. Ay no. Dito yung sa server. Ayan ito na yung load balancer yung kabuuan na 'yan. Hindi ko pa pala naayos

55:00 yan. Then after that, dito naman is yung sa database natin. So yan yan yung tinatawag na layered system. Okay. So hindi kinakailangan malaman ng mobile application kung ilang layer ang dadaanan ng request from the client per purpose first ano ba to? Perspective [tawanan] nabulol ako from client perspective client API 'di ba? Pero behind the scene so ang dami niyang pinagdadaanan from the client. from the um API, from the load

55:48 balancing, meron pa siyang dinadaanan na reverse proxy tapos dadaan pa siya sa application server tapos sa database. So the client interact through the API without needing to understand the complete ah internal structure. Okay. So how the principle work together? Paano sila na itong limang to? Okay? So ganito siya no? So sa client server separate responsibility. Okay? Yun yung na-discuss natin. Pag client server ang pinag-uusapan separated sila ng ginagawa. Okay. Sa stateless make each request self contained with a

56:34 respect to client session state. Pag sinabi naman nating cashable, allow reusable response where appropriate. Pag sinabi naman nating uniform interface makes communication consistent and predictable pagdating doun sa pag sa pag-design natin ng API. Pagdating naman ng layered system allowing infrastructure complexity behind the interface together those properties help restbased systems become easier to scale, maintain, integrate and involve. Kasi kung naiintindihan natin to, maybe later on magdagdag tayo ng um sa interface, magdagdag tayo ng mga design. Okay? Madali tayong mag-maintain, madali

57:20 nating ma-attract, madali tayong makapag-integrate because of the um principle na dapat nating i-apply. Okay. Next. Um bago tayo magano sa next slide, remember guys, kapag sinabi nating rest is not a simply HTTP plus Jason. Hindi siya lang ganon no? Rest is an architectural style and those constraint are not or are what shape the behavior and structure of a restful system. Kaya nga yung stateless and uniform

58:07 is very part nung ano, very important part pagdating doun sa um process dahil magiging directly useful yung dalawang concept na yon because of dun kasi nagi ah dun kasi ah nagi-start. Okay. Lalo na tayo kapag mga first time yung stateless and uniform dapat ang pinaka ah pagtuunan natin ng bagay and pansin kasi yun na nase-set aside eh. Like katulad nung ano katulad nito usually pag gagawa ka ng API baka makasanayan kasi. Okay. Pero mamaya ituturo natin yang get post and delete na yan. Okay.

58:55 So next tayo. So resource and URI. So resource is any object or piece of data user product and order. Each resource has a unique URI address on the web. So use nouns in the URL. The HTTP method decide the action not the URL. Okay. For example, dito student then collection of the student. Student 42 is one specific student. Pag dito naman ah student 42 then grade. So ito naman

59:41 the grade of the student. Yun naman yung parang ine-emphasize natin doon. Okay? Kapag ganun 'yung design. So sa restle guys nabanggit natin na uniform interface. So dapat consistent and predictable. Tama. So yun ang paraan ng pag-access doun sa mga resources. Ngayon, dito natin makikita kung paano yun ia-apply sa actual API design. So meron tayong dalawang important concept dito guys is si resource at URL. Si resource and URL. URI. Pag sinabi nating resource, doon natin ina-access yon. Kapag naman nating sinabing URI, ito naman is saan ma-access.

1:00:27 Okay. So uniform ah resource interface. So sa rest, ang resource is yung identifiable object identity or collection of data na gusto nating i-expose through the API. Let's say school system. So halimbawa possible resources natin is student faculty, object grade enrollment. Okay. Sa clinic system meron tayong pet client ay pet client appointment ano pa ba? Service. So hindi ibig sabihin na ang resources natin is directly equivalent sa database table.

1:01:14 Okay. Resources. Ito yung form the perspective of the API. So ito yung maaaring ang data nito is galing sa database, multiple table, another service or dynamic generated. Okay. So understanding for the URI or tinatawag nating uniform resource identifier. Ito yun yung resource uniform identifier. So may makikita ito. Makikita mo yung slash student. Ang sabi diyan the collection of all student. The represent of all um student ba pag sinabi nating

1:02:02 slash student. Ibig sabihin doon sa server ang equivalent nito yung table or database ng or record ng lahat ng mga student doun sa database. Okay? Kung isang particular lang ng student, makikita niyo yung may 42. So ibig sabihin niyan kung ang database mo 100 data ang meron doun. At kung gumagamit tayo ng ID, example ID ito. So yung nire-represent nito yung student SL 42. Ibig sabihin nandun yung number 42 or ID 42. So pag titingnan mo sa

1:02:47 database yun kunyari si One delac yun. So yun yung equivalent ng 42. Okay? Yung 42 is identifier ng specific resources. Ah yun sample ko is student ID. Okay. So meron tayong collection which is the student for individual resources. Okay. So important distinction dito guys. Ito yung ano madalas nating makikita sa actual um rest API design. Okay. So meron tayong tinatawag na nested resources. which is ito yung mayroong slash grades.

1:03:35 Sabi diyan sa slide, the grades of the student. So kung babasahin natin from right to left ay to left to right, sorry left to right. So student 42 then grade okay so grade belonging to the uh student. So meaning to say so give me the grade associ associated with student 42. Parang ganun lang yung gustong sabihin nung API. Okay? Dito natin makikita na pwedeng ipakita ng ah URI relationship between the resources. So another example

1:04:21 um SLPET/15/ appointment. So meaning to say appointment associated with PET 15. So hindi na natin kailangan gumawa ng get appointment of PET 15 mas resource oriented ang pet/15/aointment. So mas ano siya mas ah mas consistent. Okay? Mas consistent ang resource oriented ah presentation niya. Okay? So important rules guys, use nouns not action. Okay.

1:05:06 Pagdating sa uh URL, for example, less oriented um ah less rest oriented sabi natin get 'di ba? SLG student SLCTudent SL delete student 'di bailing tayo sa mga ganyan eh slash update student ' ba. So sa ano sa API design sa ano 'yun sa function pwede nating gawin 'yun 'yung mga ganung ah name 'di ba yung name ng ay function name get student create student delete student update student pwede siya pero notice guys sa URL mismo

1:05:54 meron na tayong action okay na later on idi-discuss natin we have a get delete date and update. Okay? No need na to mention doon sa ah URI. Okay. Sa rest meron na tayong mechanism para sabihin yung action na yan. Okay? Get, post, delete 'di ba? So alam natin yun. Pag get nire-retrieve natin, pag post kini-create natin, pag-delete syempre dine-delete natin yung mismong specific. So ganun din 'yun. Same din yun sa concept dito. Okay? Nagbabago lang 'yun based don sa UR ah sa http uh method depende don' sa operation 'no? Okay? So bakit nagma-matter 'yung mga design?

1:06:42 Bakit kailangan oriented siya? So imagine no kung bawat developer gumagawa ng sariling naming convention sa API design like get student, find student, search student buy ID, remove student, ano pa ba? Save New student ah edit existing student. Sabihin nating ganun yung um ano mo API design mo. Okay? So kailangan mong aralin individually kung papaano gumagana ang bawat end point 'di ba? Eh kung let's say they can provide a appropriate um design API design ' ba consistent oriented siya. Okay. Tapos plus may

1:07:27 documentation. So mas male-lessen 'di ba ah 'yung yung pagintegrate. Ikaw naman as developer. Hindi ikaw yung nagpo-provide. Developer ka. Nandun ka sa client. Kapag may nakita kang site like dito o nakita mo 'yung API documentation niya. Sample tapos nakaka-irita. nakita mo nakakairita eh junior or senior ano ka na developer ka nakakairita yung kanyang mga naming convention sa tingin mo gagamitin mo pa ba 'yun tina nakaka-time consume yun syempre lilipat ka doun sa ibang sa ibang provider na mas madaling intindihin okay

1:08:15 so mas predictable for example ganito siya get/student post/student get student student/42. Meron pa tayong tinatawag na put/student/42 or else delete/students/42. So pag gaganun yung resource oriented design natin or API design so mas madaling intindihin kahit hindi ikaw ang original na developer. Okay? Dito natin makikita yung practice for the uniform interface kung ang pag-uusapan no. Okay. So, misconception pagdating ng URI, URI alone does not completely tell us

1:09:03 the action. For example, yung SLS student/42. Okay. Hindi ah hindi natin masasabi mula sa URI alone kung gusto nating kunin, baguhin or tanggalin ang student. We need the HTTP method like get put delate. Okay. Hindi natin kung kung slash 42 lang ito o kunyari slash student/42 na yan. Hindi natin magasasabit yan. Kaya nga napaka-very important yung mga HTTP method yung get, put, delete, post na yan. Okay. Same resources different operation. Okay. Do nagkakaiba 'yun. doon nagkakatalo. Okay. Meron kang ano, meron

1:09:50 kang dalawang ganito. Student/42 pero wala ka naman nilagay na http method like a get, put, delete, post. So wala rin nonsension pag ganon. So mamaya aanuhin natin siya i-tackle natin siya. Okay. So remember guys, the URI identifies the resources. The HTTP method tells us what we want to do with that resources. Yun yung ano do yun yung essence nung dalawa. Okay? Hindi lang tayo more on resources. Ito alam natin ito yung mga resources na kayang gawin. Pero pagdating sa HTTP method yung ano naman yung kung ano yung gusto nating gawin d sa resources. Okay.

1:10:37 So next ano natin slide. [nililinis ang lalamunan] So sa Jason um ito Jason the language oppress. Okay. So connection dun sa previous slide pinag-usapan natin resource at URI. yung sample natin kanina na [nililinis ang lalamunan] SL students/42. So alam natin na ang URL nito is identify the student 42. Okay. Pero may next question tayo. Kapag ni-request natin ang student 42, paano natin ah paano paano ipapadala ng server ang actual data pabalik sa client?

1:11:25 Like yung server, paano siya magre-response? What I mean is I mean ano yung magiging response ni server pabalik? So dito pumapasok yung Jason. Ano ba yung Jason? Sabi diyan, Jason stand for JavaScript object notation. So isa itong light wave text based format for representing structured data. Ano ba yung structured data? Yan yung mga sa attributes yung name, age, address, contact number, email, status. Lahat 'yan is structured data ng

1:12:10 pinag-uusapan. 'Pag unstructured, iba na 'yun. Ah 'yan na 'yung mga text, image ay hindi, text tuloy. Ah image, video 'yan na 'yan na 'yung mga uninstructured. Pero ang pinag-uusapan natin pagdating kay Jason is representing for structured data. Okay. For example, instead na mag-return ang server ng ganito, unstructured text sabi niya 42 del Cruz Bit. True. So pepwedeng ibigay ganito. Naka nakaano siya naka Jason. Sabay kanina.

1:12:56 Ay nandun pala sa ano yung ginawa ko kanina. Ito ganito siya. Okay. So mas malinaw ngayon kung anong meaning nung bawat value dahil gumagamit tayo ng key value pairs. Ito. [sumisingasing] Ito pala meron pala tayo. Ito yan yang key value first which is yung ID is the represent 42 tapos name. So lahat ng mga nung arrangement niya is yung una yung ah key values which is yung ID. So lahat yun is naka double cotation. Tapos yun dito yung assignment operating colon and then the value. Pagka number

1:13:44 okay lang na walang um double condition. Tapos yung kama is represent para dun sa next na key value pairs. Tapos may makikita ka na value na meroong double cotation. So string ang tawag doon. Okay? So alam niyo naman kapagka ah true or false equivalent yan as yan. Okay. So ito yung reason kung bakit convenient ang Jason for exchanging structured data between application. So how it fit into a rest API? So balikan natin yung resource natin kanina yung get/student/42.

1:14:32 So yung nangyayari diyan is from client sabihin nating client ah nag-request siya so get student 42 and then rest API. So find prepare the student data from server. So Jason response ang magiging ang magiging response ni server is Jason Jason type. Okay? Yun yung ipapadala niya. Okay? Papunta kay client or pabalik kay client. So possible response non is yung sample. Yan ah ID 42 name Juan Delacus um course BSIT and active

1:15:18 true. Okay. So ang Jason dito is representation ng student resources na hiningi natin. Okay so connect natin dun sa previous rest concept. So sa resource yung student yung URI which is SL42 ay SLS student 42 and representation niya is Jason. Okay. So ito na ngayon ang practical meaning na sinasabi natin earlier na rest transfer representation of resources. Okay? Kaya balik tayo d sa una doon sa rest.

1:16:03 representation state transfer. Okay? Kaya siya tinawag na ganon. Okay. So next. So tandaan niyo guys, itong part na to is object. Kaya nga si ano yan eh. Ayan o. JavaScript object notation. So meron siyang curly braces. Okay. At meron tayong key value pair sa loob. Yun yung pinag-usapan natin kanina. Okay. Inside inside the object meron tayong mga key value fairs. Yung key value fairs yung name tapos one dela cruz.

1:16:48 So yung name is 'yung key. Okay? And then 'yung one dela cruz. is 'yung value kaya tinawag siya na key value pairs. So another example, ayan yung active and then true. So ito is yung key. Ito naman is yung value. Okay? So yung yung ito is buan yan eh. So ine-emphasize natin uh Jason properly yung name keys must use double cotation.

1:17:35 Okay? Hindi bale ah sa Jason ang paggamit ng single quotation for key and string. Laging double quotation. Paki-take note na lang yan. Okay. Even dun sa ano sa value sa key automatically double quotation sa ano natin ba may mga ano tayo character car or char na tinatawag. So alam natin kapag ganitong double cotation is string. So hindi na natin masyadong paligoy-ligo yan dahil alam niyo na yan. Okay? Nagc2 na kayo pag number alam natin yun. int 'yan kapagka may that 'yan float 'di ba?

1:18:21 Kapag ganito, true all false, alam natin na volan 'yan. Okay. Number three, which is the um ano ba yung ano natin dito? Yung Jason type. Okay? Kasi hindi lahat ng values ay string. Okay? Support yan with the several types 'di ba? So pwede pa tayong mag-null. Ano ba yung null? Wala siyang totally ' ba? Wala siyang totaling value pagka ganon. Number um buan, string, char. Okay. So value can also contains object and array. So pwede

1:19:07 ring array. Okay. Paano ba kapag-aray guys? Let's say ganito ah. Mas mas maganda to. Ito ganito. Instead na gawin mo ' ba kasi yung iba hindi ako i-apply 'yung ano eh is aawa ko din kung minsan kung may mga ganung ano may mga ganng instance. Pero guys, papapansin ko lang 'to sa inyo. 'Di ba? Subject. [nililinis ang lalamunan] Ah subject. Ayan. Tama ba? Parang mali. Ah subject

1:19:54 yan. Tapos lagay tayo ng value. Okay. Web development. Ayan. Eh meron meron ulit isang ano ba merong ulit isang subject. Sabayin natin ng subject is subject um IPT1. Ayan. So ayan mag--error 'yan kasi same

1:20:40 lang sila 'di ba? So ang gagawin natin diyan lalagyan natin ng difference ' ba? Subject one, subject 2. So pwede mo namang gawin is mas appropriate diyan ganito. Umm dali ka ba tayo? Subject. Tapos yung value natin will be naka-array. Okay. Doon na natin ipasok 'to. Tapos IPT1.

1:21:27 Okay. Yan. Mas organize siya 'di ba? So yung associative pwede mo rin lagyan dito kung gusto mo associative. Walang problema yon. Okay. Square bracket represent as array. dun sa list of values. Okay? Instead na ganito yung gawin mo, subject one, subject 2, meron ka na namang key na subject 3 eh ka na lang subject and then lagay mo na lang yung ah list nung values dito

1:22:13 inside the bracket. Okay. So meron din tinatawag na um nested. Okay. Nested sa real API response pupwedeng mas structured yung data. For example, ah ID 42, name Juan Dela Cruz tapos course 'di ba? Meron may yung course merong ah sabihin nating ang course meron pa siyang other information. So pwede tayong magano do mag-rest ay mag-nested. Let's say dito pakita ko

1:23:00 yan. Subject one ' ba ah ' ba una may ID tayo. Kunyari ang ID mo is 42. Okay? And then diyan baba ko lang para maganon ng space yan. Tapos meron kang course. Okay. Meron kang course to inside niyan is nakaano rin. Yan naka may curly braces din. Okay. So course sabung code

1:23:53 um ano bang code ah BSIT tapos year level year level 3. Okay, sabay nating ganyan. Ayan. Okay. So inside dun sa may ano mo structured mo. So meron kang nested, meron kang another na naka-Jason ah part doun sa loob. Okay. Meron kang

1:24:40 ID, may name kunyari may name diyan to scores tapos meron kang array na nakaob array na ano na value. Okay. Parang inside the inside the object meron kang object. Okay. Gann siya. So 'yung common ano dito uh misconception dito guys is 'yung Jason is not a JavaScript object itself. Okay? Kasi parang ano yun eh parang magkaano sila, magka-same sila sa syntax 'di ba? T's galing sila sa JavaScript yung pangalan. Pero yung Jason is a data

1:25:26 interchange format that can be used by many programming languages. For example, sa PHP Jason, sa JavaScript Jason, sa Python may Jason, sa Java may Jason, sa C+ may Jason. Ah kung kaya pwedeng sabihin natin PHP ang backend natin tapos JavaScript naman ang front end. Pero ah naintindihan nilang parehas yung exchange Jason after piercing orarization. So bakit nagma-matter? Kasi ito yung magiging common pattern natin para gumawa tayo ng rest API. Okay? Bakit nagma-matter itong ah Jason? O let's say

1:26:12 sa client magre-request siya through HTTP tapos 'yung ating rest API t's ipa-process 'yan. Okay. Pag process niyan, magiging response niyan is naka-Jason. Okay. So ang first natin doon is Jason pagdating kay client. Okay. So from this point ah huwag nating tignan yyung Jason as a run random syntax lang. It is a structured representation of data being exchanged between the system. Okay. So remember guys, UI tells us which resources we are accessing.

1:26:58 Jason is common format used to represent the data exchange in the request or response. Okay. Next, [nililinis ang lalamunan] ito na yung mga ano natin yung mga crude natin sa HTTP method. Ayung sinasabi natin kanina na get post put patch tsaka delete. Okay? Kanina guys so inestablish natin yung URI which is identifies the resource and Jason is commonly represent the data being exchanged. Ngayon naman kulang pa tayo ng isang important information which is ano yung gusto nating gawin sa

1:27:43 resources. So dito pumapasok 'yung tinatawag na HTTP method. So example ah parehas nating ginagamit ang student SL42 pero pupwede nating gustong gawin na kunin, palitan, partially i-update or tanggalin ng student. So sa HTTP method communicate. Intent. Okay. So makikita niyo sa table guys, ayan yung related doun sa common HTTP method which is the crude operation. Okay? Yung crude HTTP method meaning ' ba. Okay yan yung mga dapat niyong ah

1:28:32 tandaan. Okay which is the get read, retrieve resources etc etc. Pero tandaan niyo yung CR code is a data operation concept while get post patch put and delete our HTTP method. So this is a convenient uh for mapping pero hindi sila yung literally the same concept. Parang sinasabi lang natin is crude. Alam naman natin pag sinabing crude is yan 'yung operation. Okay. Pero 'yung ating HTT ay http method, ito yung gagamitin natin. Okay? So let's say sa get read T's ang purpose niya is

1:29:19 retrieve the resources. So kukunin lang natin. Okay. Suppose naman is create. Ito naman yung ang purpose naman nito is to add a new resources. Okay. Doun muna tayo sa read. Kapag read, gusto nating mag-retrieve ng resources, commonly ang gagamitin natin diyan is get. Example, get/42 ay get/student/42. So meaning to say ang magiging possible response nito will be um ID 42 ' ba name one dela Cruz tapos course BSIT. For all student

1:30:04 syempre ang gamitin lang natin is get slstudent. Okay? Wala tayong ano, wala tayong i-specific kasi pag may specific merong slash 42. Pag wala yung lahat ng meron lahat ng record na meron doun sa student. So get should uh should be used for retrieving information not for intentionally changing server state. Okay. Next. Post or create. Kapag gusto nating gumawa ng new resources commonly ang gagamitin natin is post student. this time. So kailangan nating um i-send ang information for the new

1:30:51 student. Okay. Possible na request na possible request body natin doon will be name Maria Santos. Tapos ang course niya is BSCS. So paano yung process non? So post student tapos plus yung student data niya and then the server create a create the new resource. So new student ba. And then um ito notice guys kapag ka post student. So meaning to say wait lang may kukunin lang ako may aking [sumisingasing] ano kahit sa mata.

1:31:43 Wait lang. Gin ko yung salamin ko ang labo. Wait lang guys. Okay. Notice guys kapag sinabi nating um post/student ah ang ginagamit natin doon is post/student/ 43. Ito yung common na ano common cases

1:32:31 where the server generate the new uh resources ID. Okay. Next. Put or replace. So dito naman kay put kailangan nating i-distinguish okay carefully itong um patch kasi normally para siyang nag-a-update eh. Pero doun muna tayo kay ano kay put. Put is commonly used when the client sent a complete replacement representation of resources. For example, existing resources we have a 421 dela Cruz BSIT year level is third

1:33:16 year. Then sa put ah let's say student 42 tapos sa request body niya um ang courses niya na dati is VSIT ngayon ang gig BSCS. So ito na yung updated representation ng student 42 which is BS dating IT naging BSCS. Okay. So ito in emphasize lang natin that put replace the target resources representation. Okay. Pagdating naman ng patch, ito yung partial update kung tawagin.

1:34:05 Okay. Kapag patch naman, um pinag-uusapan is yung part lang ng resources ang gusto nating baguhin. Okay. Suppose meron tayong course na course lang yung babaguhin natin. Let's say BSCS. BSIT. So babaguhin natin siya into BS CS. So hindi na natin kailangan ipadala lahat ng other field kung hindi naman natin sila binabago. Okay? So ano yung distinction ng dalawa? Pagpot replace the resource representation. Pagpat naman, modified part of the resources.

1:34:50 So sa put pwede mong i-include lahat ng failed tapos specific na i-update mo. Pero sa patch pwede mong gawin na kahit yung isang field langung na imo-modified mo ang um ang i-update kasi sa patch is partial lang eh. partial lang ng mga resources na gusto mong baguhin. Okay. Next, for the delete. So, ito naman for this for the words na delete, kung gusto mong i-specify na alisin yung specific na resources like yung SL student/42. So meaning remove the the student resources identified by 42. Kumbaga sa database remove na yung 42 na

1:35:39 yun. Okay. Notice na hindi natin ginagamit yung ah delete student ay SLD student/42 because the action is already communicated by delete. Kaya nga ang pangit ng ano e ang pangit ng API design mo kung ganun 'yung gagawin mo. Parang ang nangyari doon ganito siya 'di ba? Ah, remove tapos t's gagamit ka ng HTTP 'di ba? Let's say ganito http tapos ang design mo is dot http okay lagagay natin to. Delete.

1:36:26 Parehas lang naman eh. delete pet yung ID 15 so ' ba hindi siya magandang design kasi nga meron na tayong method to identify kung ano yung action natin eh kaya nga sabi nga is name hindi action ang ating naming convention okay So next tayo. So self and idemptent method. So ano naman ong dalawang to? So kanina so pinag-usapan natinung mga

1:37:12 method like yung get, posch and delate. Ngayon may isang importanteng behavor na kailangan nating maintindihan tungkol dun sa mga method. Kapag ang request ba ay inulit. Ano yung magiging epekto non sa server? So dito pumapasok yung dalawang concept na safe and idem potent. So doon muna tayo sa safe. Sa safe sabi diyan the method only read data and never exchange it. Yun ang safe. Kapag sinabi nating ah kapag sinabi nating HTTP method is safe, ang intention nito ay read only. ba hindi natin ginagamit para

1:37:57 ah let's say mabago yung state ng resources let's say sa get o alam natin ang get ba suppose ang current student is ay 42 one dela bas so pagka ginawa natin is gets/students/42 so ang intensyon lang natin doon is kunin ah I-retrieve lang yung information. Okay? Eh kapag ulit ah kapag laging inuulit yung request, let's say nag-get ka na ng student 42 na-get na naman. So hindi ah hindi dapat maging ano yun um student delete or update or new

1:38:43 student created. Kasi sa ano natin sa intention natin nagre-retrieve lang tayo. Okay? So this is the important clarification that the safe is hindi nanganghuhulugan na nothing at all happens on the server. Okay. For example, uh get request can still result in server log being written, analytics being recorded, cash being update. So ang ibig sabihin ng safe ay hindi um hindi paano ba yung words na yon? Yung hindi sa part ng client yung nagbabago ng target or resources ng state as the

1:39:30 purpose of the method. Okay? Yung state is ah absolutely walang nagbabago anytime sa pagre-request. Kaya nga para siyang tinawag na ano eh, read only. Ayan oh. The method only read the data and never exchange it. Paano naman yung idem potent? Ang sabi diyan calling it once or many times has the same final effect. So ito mas interesting ang idemptent kasi yung method na ang method is idempotent kapag calling the same request once or multiple times has the

1:40:17 same intended final effect on the server state. Paano yun? Hindi ibig sabihin kasi na identical palagi iyung response. Okay? So ang pinag-uusapan natin dito is yung final intended state. Okay, let's say ganito siya. Put example, itong put suppose mayron tayong put/ student/42. So ang maybe ang response niyan is one dela Cruz tas BS CS. So first request BSIT to BSCS accidentally naulit. So foot/student/42

1:41:04 same body one del cruz BSCS so ano ang final state BSCS course na BSCS so kung uulitin pa natin ng 10 10 times same intended final state BSCS pa rin yung magiging ano non magiging value ni Kina Coursese Okay, that's why put is id potent. Okay, ito guys binibigyan lang natin ng ano ng um binibigyan natin ng definition yung pinaka-essence nung behavior nung nung ano nung mga method which is the safe

1:41:52 and idemptent. Bakit hindi si post Bakit si post hindi siya usually ano not idemptent ba now ito kasi guys pagka sapose sl2 ba yung body niya let's say ang body ni is Maria Santos B it sa first request so 10 sabihin natin first request student 101 created tapos if The same post is sent again. Student 102 created. Again, student 103 created. Possible result non at post at once ' ba? POS once tapos one resources.

1:42:39 Pagka post three times, syempre potentially ang mangyayari doon three times din yung resources. Okay. The final effect keep changing kaya yung post is generally not idemptent. Okay. O naman. Bakit naman si delete is idem potent? Because ito medyo nakakalito to eh sa delete. Bakit si ident is ah si delete is potent? Let's say um delete/42 ay delete/student/42. First sequest natin kunwari 42

1:43:27 um student 42 exist so later on student 42 delete then accidentally naulit ulit yung yung ah yung request na delete/42 ay delete/ student/42. So possible na sasabihin ni server na 404 not found. Kasi wala na ' ba na delated na eh. So because wala na si student 42 so baka sabihin baka sabihin ninyo ganito sir different response na eh. Bakit idot? Bakit identify yyung final state

1:44:13 not whether every response is identical. Okay. After the after the first request which is the student 42 does not exist after the second request student 42 does not exist. Okay. After the 10th request student 42 does not exist. So same intended final state therefore um delete is idemp potent sa ano 'to sa kung matatandaan ninyo sa um DS1. Okay. So what about patch?

1:45:01 Dito kailangan ng konting caution kasi patch is not guaranteed to be idotent. Depende to sa operation na ginagawa ng patch. for example pero usually nakalagay diyan usually no patch um/students 42 okay and then ang nakalagay doon ah is course bsscs 'di ba yun yung papalitan so for ah interpret if interpreted as set the course to bscs so repeating it can produce the same final state But imagine an API operation uh semantic

1:45:47 [sumisingasing] effectively means increment login count by one. Parang first request 10 to 11, second request is 11 12 the third request is 12 to 13 different final effect every time. Okay. So that's why we should not assume that every patch is request is ident potent. Okay. Medyo nakakalito lang si ano sich. Hindi kasi siya nagga-garantee as item potent because of that. Kasi kung sa ano lang ah sa repeating

1:46:32 lang dun sa pag-produce sa final state kasi sa part naman ng operation nagme-make sense naman yung effectedly niya by increment ' ba. Kaya different final affect every time that that we should not assume that every patch is request is idemp potent. I usually so difference ni safe and ident potentag safe so as if this method is intended only to retrieve rate rather than the request or

1:47:21 exchange state change sinabi natin potent as if I repeat If I repeat the same request does not intended the final server state remains the same. Okay. So guys, um pag sinabi nating safe, ulitin ko lang intended not to change resource state. Pag sinabi na natin ay demotent, repeating the same request has the same intended final effect. Okay. So next tayo. So dito naman guys meron tayong mga HTTP

1:48:09 status code. Okay? So alamin natin 'tong mga 'to. So kanina na-identify natin yung mga request yung get post, patch, put delete, update ba mga ganyan. Pero pagkatapos pagkatapos non syempre dapat ipa-process 'yan. So kailangan ah kailangan nito sabihin sa client ano ang nangyayari sa request mo. So dito dito natin ginagamit yung tinatawag na HTTP status. So hindi lang data ang response ng API. May status code din na lalabas doon sa part pagka nag-aano na 'ag nag-respond. Nagsasabi kung successful ba ang

1:48:55 request. May problema ba sa request or may problema mismo sa server? Okay. So ang HTTP status ay merong three digit number na kasama dun sa HTTP response. So instead na hulaan natin, hulaan ng client kung successful ba ang operation, meron tayong standardized category. Kumbaga kung ikaw ang developer don' sa client in-integrate mo then after that nagkaroon ng problem hindi ka pwedeng hindi hindi mo basta basta siya huhulaan meron tayong standard code. Pagka 2 2x success ayan pag 3xx

1:49:40 redirection pag 4xx client error tapos pag 5 server error. Okay yan na 'yung four. Ayan yung sa client error yung 404 ganyan. Yung sa server naman is five. Okay. So kapag two successful, kapag four may issue related sa request or client side, pagka naman five is server side failure yung ayan oh. [nililinis ang lalamunan] Meron tayong ah 2001 204. Ayan yung mga yan makikita natin. Okay.

1:50:25 Pag redirection naman ng pinag-uusapan yan 301 304. Pagka naman na client which is nagkaroon ayan oh yung 404 kung minsan na-encounter natin yan 401 ah 400 pagdating naman ng pagka 500 naman so internal naman ito sa server naman ang error nito. Okay. 503. Okay. So lahat ng yan. So pagka two ang sinasabi natin success 'yan. So meaning the server successfully re ah received and handle the request. Pero hindi lahat ng request ay pare-pareho ang appropriate status. So merong 200 sabihin is okay.

1:51:11 Common yan kapag successful ang request at may response content. Let's say get student 42. Kapag sinabi niyang http/1.1 ibig sabihin okay 200 ibig sabihin okay yun. Kumbaga yung content type which is application Jason na padala yun meaning successful ang request ito yung result. Okay. Kapag naman ang 2011, ito naman is 'yung mga common kapag successful created and new ang new resources. Parang gann pagka-created ang pinag-uusapan 2011. Kapag naman na 204 ito naman is no content. Successful ang

1:51:58 operation pero walang response body na kailang kailangan ibalik. Okay. Like for example, nag-delete ka lang. So ibig sabihin 404 wala namang binabalik na response yun ' ba. So successful ang request pero wala naman siyang response. Okay. Next sa 3 or 300 plus red direction. So pag ito naman sa sa three family ang generally related ito sa read direction or use for another representation location or cash related condition. So meron tayong dalawa diyan which is 301 and 304. Pag sinabi nating 301, move permanently.

1:52:43 Indicate na permanently move ang request to another location. From example, old URL1 siya ' ba move permanently to the new URL. So pag sinabi naman nating 304 not modified, ito naman yung commonly connected sa HTTP cashing. Yung pagka nag-cash copy na ang client pagdating doon and then hindi naman nabago 'yung resources. Maaring sabihin ng server na three of four or not modified. So parang sa konsepto nito is hindi naman nababago yung resources. So may mga continue lang ah may may mga

1:53:30 continue ah cash representation lang. Okay. So pagdating naman ng four, ito na yung mga errors tsaka yung pipe. Okay? Yung four naman means may problem sa request or the client does not meet what is required to successful process. So number one diyan is yung 400. Pag sinabi nating 400, ito yung mga bad requests. So ibig sabihin invalid or malform ang requests. For example, sa postudent suppose ah required ang name pero ito lang nilagay mo yung course and BSIT. So

1:54:17 possible na magkakaroon ng uh response na 400 which is the server is essentially saying na may problema sa request na pinadala mo. So ano yung ano yung problema doon? Syempre kulang yung field na ano field which is yung name. Ngayon

…