1
00:00:01,670 --> 00:00:04,320
‫Instruktur: Jadi sekarang kita tahu apa itu

2
00:00:04,320 --> 00:00:07,550
‫Express, kita hampir siap untuk mulai membangun API kita.

3
00:00:07,550 --> 00:00:08,890
‫Namun sebelum kita

4
00:00:08,890 --> 00:00:12,300
‫melakukannya, saya perlu membahas API di tingkat yang lebih tinggi

5
00:00:12,300 --> 00:00:13,910
‫dengan cepat, dan yang

6
00:00:13,910 --> 00:00:16,370
‫lebih penting, memperkenalkan Anda pada Arsitektur REST

7
00:00:16,370 --> 00:00:19,640
‫yang merupakan arsitektur API yang paling banyak digunakan saat ini.

8
00:00:19,640 --> 00:00:23,270
‫Dengan cara ini, kita akan benar-benar tahu apa yang sedang kita bangun.

9
00:00:23,270 --> 00:00:25,710
‫Jadi sangat penting untuk memahami hal-hal

10
00:00:25,710 --> 00:00:27,860
‫dalam video ini sebelum melanjutkan,

11
00:00:27,860 --> 00:00:30,580
‫sehingga kita benar-benar tahu apa yang kita

12
00:00:30,580 --> 00:00:32,603
‫bangun sepanjang sisa kursus.

13
00:00:33,630 --> 00:00:34,890
‫Pertama-tama, API

14
00:00:34,890 --> 00:00:38,390
‫adalah singkatan dari Application Programming Interface dan pada tingkat

15
00:00:38,390 --> 00:00:40,130
‫yang sangat tinggi, itu

16
00:00:40,130 --> 00:00:43,150
‫pada dasarnya adalah perangkat lunak yang dapat

17
00:00:43,150 --> 00:00:45,270
‫digunakan oleh perangkat lunak lain

18
00:00:45,270 --> 00:00:48,213
‫untuk memungkinkan aplikasi berbicara satu sama lain.

19
00:00:49,080 --> 00:00:51,420
‫Kami sebenarnya telah berbicara tentang

20
00:00:51,420 --> 00:00:53,780
‫API sebelumnya, lebih khusus lagi, API web,

21
00:00:53,780 --> 00:00:56,300
‫di mana kami hanya membangun sebuah aplikasi

22
00:00:56,300 --> 00:00:59,640
‫yang mengirimkan data ke klien setiap kali ada permintaan masuk.

23
00:00:59,640 --> 00:01:02,530
‫Bayangkan kami menjalankan aplikasi kami di server dan

24
00:01:02,530 --> 00:01:04,060
‫kami memiliki klien.

25
00:01:04,060 --> 00:01:08,020
‫Jadi sebenarnya, kita secara efektif memiliki dua perangkat lunak yang

26
00:01:08,020 --> 00:01:10,250
‫berbicara satu sama lain, bukan?

27
00:01:10,250 --> 00:01:13,550
‫Dan ini adalah jenis API yang akan kita bangun dalam kursus ini.

28
00:01:13,550 --> 00:01:17,470
‫Dan saya rasa itu adalah jenis API yang paling banyak digunakan di luar sana.

29
00:01:17,470 --> 00:01:21,970
‫Namun nyatanya, API tidak hanya digunakan untuk mengirim data, dan tidak

30
00:01:21,970 --> 00:01:25,493
‫selalu terkait dengan pengembangan web atau JavaScript.

31
00:01:26,400 --> 00:01:29,500
‫Aplikasi dalam API sebenarnya dapat berarti

32
00:01:29,500 --> 00:01:32,710
‫banyak hal yang berbeda selama perangkat lunak

33
00:01:32,710 --> 00:01:35,050
‫tersebut relatif berdiri sendiri.

34
00:01:35,050 --> 00:01:35,900
‫Ambil

35
00:01:35,900 --> 00:01:38,870
‫contoh, Sistem File Node, atau Modul HTTP.

36
00:01:38,870 --> 00:01:42,010
‫Kita dapat mengatakan bahwa mereka adalah bagian kecil dari

37
00:01:42,010 --> 00:01:43,110
‫perangkat lunak dan

38
00:01:43,110 --> 00:01:46,970
‫kita dapat menggunakannya, kita dapat berinteraksi dengan mereka dengan menggunakan API mereka.

39
00:01:46,970 --> 00:01:47,803
‫Misalnya,

40
00:01:47,803 --> 00:01:51,150
‫ketika kita menggunakan fungsi readfile dari Modul

41
00:01:51,150 --> 00:01:54,020
‫FS, kita sebenarnya menggunakan FS API.

42
00:01:54,020 --> 00:01:57,380
‫Dan itulah mengapa Anda terkadang mendengar istilah node API.

43
00:01:57,380 --> 00:02:01,090
‫Dan itu biasanya hanya mengacu pada modul simpul inti yang

44
00:02:01,090 --> 00:02:02,920
‫dapat berinteraksi dengan kita.

45
00:02:02,920 --> 00:02:05,670
‫Atau ketika kita melakukan manipulasi DOM di

46
00:02:05,670 --> 00:02:08,650
‫browser, kita tidak benar-benar menggunakan bahasa JavaScript itu

47
00:02:08,650 --> 00:02:12,440
‫sendiri, melainkan, DOM API yang diperlihatkan browser kepada kita, sehingga memberi

48
00:02:12,440 --> 00:02:14,280
‫kita akses ke sana.

49
00:02:14,280 --> 00:02:15,930
‫Atau bahkan contoh lain, katakanlah

50
00:02:15,930 --> 00:02:19,080
‫kita membuat kelas dalam bahasa pemrograman apa pun seperti

51
00:02:19,080 --> 00:02:21,940
‫Java dan kemudian menambahkan beberapa metode atau properti

52
00:02:21,940 --> 00:02:23,420
‫publik ke dalamnya.

53
00:02:23,420 --> 00:02:26,860
‫Metode-metode ini kemudian akan menjadi API dari setiap

54
00:02:26,860 --> 00:02:29,450
‫objek yang dibuat dari kelas itu

55
00:02:29,450 --> 00:02:31,890
‫karena kami memberikan perangkat lunak lain

56
00:02:31,890 --> 00:02:35,420
‫kemungkinan untuk berinteraksi dengan perangkat lunak awal kami, objek,

57
00:02:35,420 --> 00:02:37,278
‫dalam kasus ini.

58
00:02:37,278 --> 00:02:40,810
‫Soalnya, API sebenarnya memiliki arti yang lebih luas dari

59
00:02:40,810 --> 00:02:42,810
‫sekadar membangun API web.

60
00:02:42,810 --> 00:02:47,420
‫Baiklah? Bagaimanapun, API web adalah yang

61
00:02:47,420 --> 00:02:50,340
‫paling penting bagi kami dalam konteks catatan.

62
00:02:50,340 --> 00:02:53,050
‫Sekarang mari kita lihat Arsitektur REST untuk

63
00:02:53,050 --> 00:02:54,203
‫membangun API.

64
00:02:55,820 --> 00:02:59,910
‫REST, yang merupakan singkatan dari Representational States Transfer, pada dasarnya

65
00:02:59,910 --> 00:03:03,930
‫adalah cara membangun API web dengan cara yang logis, membuatnya

66
00:03:03,930 --> 00:03:06,060
‫mudah untuk dikonsumsi karena

67
00:03:06,060 --> 00:03:09,420
‫ingat, kita membangun API untuk diri kita sendiri

68
00:03:09,420 --> 00:03:12,023
‫atau untuk dikonsumsi orang lain, oke?

69
00:03:12,023 --> 00:03:15,640
‫Kami ingin membuat proses penggunaan API semulus

70
00:03:15,640 --> 00:03:17,633
‫mungkin bagi pengguna.

71
00:03:18,490 --> 00:03:20,830
‫Sekarang, untuk membangun RESTful

72
00:03:20,830 --> 00:03:24,180
‫API, yang berarti API mengikuti Arsitektur REST,

73
00:03:24,180 --> 00:03:26,660
‫kita hanya perlu mengikuti beberapa prinsip.

74
00:03:26,660 --> 00:03:31,240
‫Pertama, kita perlu memisahkan API kita menjadi sumber daya logis.

75
00:03:31,240 --> 00:03:33,860
‫Sumber daya ini kemudian harus diekspos,

76
00:03:33,860 --> 00:03:35,900
‫yang berarti tersedia

77
00:03:35,900 --> 00:03:39,420
‫menggunakan URL berbasis sumber daya yang terstruktur.

78
00:03:39,420 --> 00:03:41,460
‫Untuk melakukan tindakan yang

79
00:03:41,460 --> 00:03:44,677
‫berbeda pada data seperti membaca atau membuat atau

80
00:03:44,677 --> 00:03:49,677
‫menghapus data, API harus menggunakan metode HTP yang tepat dan bukan URL.

81
00:03:50,270 --> 00:03:53,210
‫Sekarang, data yang sebenarnya kami kirim kembali ke

82
00:03:53,210 --> 00:03:55,420
‫klien atau yang kami terima

83
00:03:55,420 --> 00:03:58,030
‫dari klien biasanya harus menggunakan format data

84
00:03:58,030 --> 00:04:01,010
‫JSON, di mana beberapa standar pemformatan diterapkan padanya.

85
00:04:01,010 --> 00:04:04,500
‫Akhirnya, prinsip penting lainnya dari REST API

86
00:04:04,500 --> 00:04:07,560
‫adalah bahwa mereka harus stateless.

87
00:04:07,560 --> 00:04:09,950
‫Jadi ini adalah gambaran yang sangat luas.

88
00:04:09,950 --> 00:04:12,030
‫Sekarang mari kita mulai berbicara tentang prinsip-prinsip

89
00:04:12,030 --> 00:04:15,310
‫ini satu per satu dimulai dengan sumber daya dan menggunakan

90
00:04:15,310 --> 00:04:17,810
‫Nators API yang akan kita buat dalam kursus

91
00:04:17,810 --> 00:04:19,803
‫ini sebagai contoh di sini.

92
00:04:20,960 --> 00:04:24,910
‫Abstraksi utama informasi di REST adalah sumber daya, dan oleh

93
00:04:24,910 --> 00:04:27,450
‫karena itu semua data yang

94
00:04:27,450 --> 00:04:32,040
‫ingin kami bagikan di API harus dibagi menjadi sumber daya logis.

95
00:04:32,040 --> 00:04:34,350
‫Sekarang, apa sebenarnya sumber daya itu?

96
00:04:34,350 --> 00:04:36,380
‫Nah, dalam konteks REST,

97
00:04:36,380 --> 00:04:39,520
‫itu adalah objek atau representasi dari sesuatu yang

98
00:04:39,520 --> 00:04:42,020
‫memiliki beberapa data yang terkait dengannya.

99
00:04:42,020 --> 00:04:42,853
‫Misalnya,

100
00:04:42,853 --> 00:04:45,570
‫tur, atau pengguna, atau ulasan dalam

101
00:04:45,570 --> 00:04:48,020
‫kasus contoh yang kami ikuti.

102
00:04:48,020 --> 00:04:50,730
‫Jadi pada dasarnya, informasi apa pun yang dapat disebutkan

103
00:04:50,730 --> 00:04:53,040
‫namanya dapat menjadi sumber daya, oke?

104
00:04:53,040 --> 00:04:56,050
‫Itu hanya harus nama, bukan kata kerja.

105
00:04:56,050 --> 00:04:57,690
‫Sekarang, kita

106
00:04:57,690 --> 00:04:59,480
‫perlu mengekspos, yang berarti

107
00:04:59,480 --> 00:05:02,520
‫menyediakan, data menggunakan beberapa URL terstruktur yang

108
00:05:02,520 --> 00:05:04,890
‫dapat dikirimi permintaan oleh klien.

109
00:05:04,890 --> 00:05:07,611
‫Misalnya, sesuatu seperti ini.

110
00:05:07,611 --> 00:05:10,740
‫Seluruh alamat ini disebut URL

111
00:05:10,740 --> 00:05:14,323
‫dan /addNewTour ini disebut Titik Akhir API.

112
00:05:15,269 --> 00:05:17,840
‫API kami akan memiliki banyak titik akhir yang

113
00:05:17,840 --> 00:05:20,560
‫berbeda seperti titik akhir fiksi yang saya miliki di

114
00:05:20,560 --> 00:05:23,730
‫sini, yang masing-masing akan mengirim data yang berbeda kembali ke

115
00:05:23,730 --> 00:05:26,150
‫klien atau juga melakukan tindakan yang berbeda.

116
00:05:26,150 --> 00:05:28,440
‫Sekarang, sebenarnya ada sesuatu yang

117
00:05:28,440 --> 00:05:31,750
‫sangat salah dengan titik akhir ini di sini karena

118
00:05:31,750 --> 00:05:34,827
‫mereka benar-benar tidak mengikuti aturan ketiga yang mengatakan

119
00:05:34,827 --> 00:05:39,110
‫bahwa kita hanya boleh menggunakan metode HTTP untuk melakukan tindakan pada data.

120
00:05:39,110 --> 00:05:42,360
‫Jadi, titik akhir seharusnya hanya berisi sumber daya kami dan

121
00:05:42,360 --> 00:05:45,070
‫bukan tindakan yang dapat dilakukan pada mereka

122
00:05:45,070 --> 00:05:48,313
‫karena mereka akan dengan cepat menjadi mimpi buruk untuk dipertahankan.

123
00:05:49,644 --> 00:05:54,210
‫Bagaimana seharusnya kita menggunakan metode HTTP ini dalam praktik?

124
00:05:54,210 --> 00:05:56,120
‫Nah, mari kita lihat

125
00:05:56,120 --> 00:05:59,620
‫bagaimana seharusnya titik akhir ini dimulai dengan /getTour.

126
00:05:59,620 --> 00:06:03,290
‫Jadi titik akhir /getTour ini adalah untuk mendapatkan data tentang tur.

127
00:06:03,290 --> 00:06:06,240
‫Jadi kita cukup menamai titik akhir /tours dan

128
00:06:06,240 --> 00:06:08,740
‫mengirim data setiap kali permintaan get dibuat

129
00:06:08,740 --> 00:06:10,430
‫ke titik akhir ini.

130
00:06:10,430 --> 00:06:11,650
‫Jadi dengan

131
00:06:11,650 --> 00:06:14,730
‫kata lain, ketika klien menggunakan metode GET

132
00:06:14,730 --> 00:06:16,700
‫HTTP untuk mengakses titik akhir.

133
00:06:16,700 --> 00:06:17,870
‫Dan seperti

134
00:06:17,870 --> 00:06:20,220
‫ini, kami hanya memiliki sumber daya

135
00:06:20,220 --> 00:06:23,670
‫di titik akhir atau di URL dan tidak ada kata

136
00:06:23,670 --> 00:06:26,870
‫kerja karena kata kerjanya sekarang dalam metode HTTP, bukan?

137
00:06:26,870 --> 00:06:27,703
‫Dan omong-omong,

138
00:06:27,703 --> 00:06:30,490
‫itu adalah praktik umum untuk selalu menggunakan nama sumber

139
00:06:30,490 --> 00:06:34,820
‫daya dalam bentuk jamak itulah sebabnya saya memiliki /tours di sini dan bukan /tour.

140
00:06:34,820 --> 00:06:37,790
‫Sekarang, konvensinya adalah ketika memanggil titik akhir

141
00:06:37,790 --> 00:06:41,820
‫itu, kita mendapatkan kembali semua tur yang ada di database, oke?

142
00:06:41,820 --> 00:06:44,820
‫Tetapi jika kita hanya ingin tur dengan satu I. D. katakanlah tujuh, kami

143
00:06:44,820 --> 00:06:48,960
‫menambahkan tujuh setelah garis miring lain atau dalam permintaan pencarian.

144
00:06:48,960 --> 00:06:50,580
‫Atau bisa juga dengan nama wisata bukan I. D. atau pengenal unik lainnya.

145
00:06:50,580 --> 00:06:53,490
‫Detailnya tidak terlalu penting saat ini, oke?

146
00:06:53,490 --> 00:06:55,410
‫Nanti, saya akan menunjukkan

147
00:06:55,410 --> 00:06:58,300
‫kepada Anda betapa mudahnya menerapkan logika semacam ini

148
00:06:58,300 --> 00:07:01,180
‫dengan Express karena di sinilah Express benar-benar bersinar.

149
00:07:01,180 --> 00:07:03,410
‫Metode HTTP atau kata kerja

150
00:07:03,410 --> 00:07:06,733
‫pertama yang dapat kita tanggapi adalah GET dan

151
00:07:07,606 --> 00:07:10,460
‫digunakan untuk melakukan operasi Baca pada data.

152
00:07:10,460 --> 00:07:12,530
‫Perhentian berikutnya, jika klien

153
00:07:12,530 --> 00:07:16,290
‫ingin membuat sumber daya baru di database kami,

154
00:07:16,290 --> 00:07:18,290
‫dalam contoh ini,

155
00:07:18,290 --> 00:07:21,450
‫tur baru, metode POST harus digunakan.

156
00:07:21,450 --> 00:07:23,200
‫Jadi kita belajar sebelumnya bahwa permintaan

157
00:07:23,200 --> 00:07:25,510
‫POST dapat digunakan untuk mengirim data ke

158
00:07:25,510 --> 00:07:28,490
‫server, jadi masuk akal untuk menggunakan POST untuk membuat

159
00:07:28,490 --> 00:07:30,230
‫sumber daya baru, bukan?

160
00:07:30,230 --> 00:07:32,270
‫Sekarang dalam kasus ini, biasanya tidak ada I. D. akan dikirim karena

161
00:07:32,270 --> 00:07:35,530
‫server harus secara otomatis mencari tahu

162
00:07:35,530 --> 00:07:38,530
‫I. D. untuk sumber daya baru.

163
00:07:38,530 --> 00:07:40,860
‫Bagaimanapun, yang benar-benar penting untuk diperhatikan di sini adalah bagaimana nama titik akhir adalah nama yang

164
00:07:40,860 --> 00:07:42,948
‫sama persis seperti sebelumnya.

165
00:07:42,948 --> 00:07:46,090
‫Satu-satunya perbedaan adalah

166
00:07:46,090 --> 00:07:50,289
‫metode HTP yang digunakan untuk permintaan.

167
00:07:50,289 --> 00:07:53,870
‫Jika titik akhir /tours diakses dengan GET, kami

168
00:07:53,870 --> 00:07:55,960
‫mengirim data ke klien.

169
00:07:55,960 --> 00:07:59,410
‫Tetapi jika titik akhir yang sama diakses dengan POST,

170
00:07:59,410 --> 00:08:01,460
‫kami mengharapkan data masuk

171
00:08:01,460 --> 00:08:04,060
‫dengan permintaan, sehingga kami dapat membuat

172
00:08:04,060 --> 00:08:06,550
‫sumber daya baru di sisi server.

173
00:08:06,550 --> 00:08:08,760
‫Jadi itu benar-benar keindahan hanya menggunakan metode HTTP daripada bermain-main

174
00:08:08,760 --> 00:08:10,330
‫dengan kata kerja dalam nama titik akhir.

175
00:08:10,330 --> 00:08:14,460
‫Sekali lagi, itu akan benar-benar menjadi tidak terkendali dengan sangat cepat.

176
00:08:14,460 --> 00:08:17,480
‫Baiklah, selanjutnya, harus ada

177
00:08:17,480 --> 00:08:21,210
‫juga kemampuan untuk memperbarui sumber daya.

178
00:08:21,210 --> 00:08:23,620
‫Dan untuk itu, baik permintaan PUT

179
00:08:23,620 --> 00:08:26,390
‫atau PATCH harus dibuat ke titik

180
00:08:26,390 --> 00:08:27,310
‫akhir.

181
00:08:27,310 --> 00:08:29,550
‫Perbedaan di antara mereka adalah bahwa

182
00:08:29,550 --> 00:08:31,550
‫dengan PUT, klien seharusnya mengirim

183
00:08:31,550 --> 00:08:33,750
‫seluruh objek yang diperbarui, sedangkan

184
00:08:33,750 --> 00:08:37,280
‫dengan PATCH, seharusnya hanya mengirim sebagian dari objek yang

185
00:08:37,280 --> 00:08:38,370
‫telah diubah.

186
00:08:38,370 --> 00:08:40,967
‫Namun keduanya memiliki kemampuan untuk

187
00:08:40,967 --> 00:08:43,060
‫mengirim data ke server.

188
00:08:43,060 --> 00:08:45,140
‫Agak seperti POST, sebenarnya, tetapi dengan maksud yang berbeda.

189
00:08:45,140 --> 00:08:46,750
‫Jadi POST adalah

190
00:08:46,750 --> 00:08:50,750
‫untuk membuat sumber daya baru, sedangkan PUT atau PATCH digunakan

191
00:08:50,750 --> 00:08:53,070
‫untuk memperbarui sumber daya yang ada

192
00:08:53,070 --> 00:08:55,370
‫dan kemudian membuat semua perbedaan.

193
00:08:55,370 --> 00:08:57,500
‫Dan akhirnya, untuk sumber

194
00:08:57,500 --> 00:08:59,660
‫sampah, ada metode HTTP DELETE.

195
00:08:59,660 --> 00:09:02,110
‫Sekali lagi, saya. D. atau pengidentifikasi unik lainnya dari sumber

196
00:09:02,110 --> 00:09:05,110
‫daya yang akan dihapus harus menjadi bagian dari

197
00:09:05,110 --> 00:09:08,010
‫URL.

198
00:09:08,010 --> 00:09:10,120
‫Sekarang, biasanya, untuk benar-benar

199
00:09:10,120 --> 00:09:11,820
‫dapat melakukan

200
00:09:11,820 --> 00:09:14,560
‫permintaan semacam ini, klien harus diautentikasi.

201
00:09:14,560 --> 00:09:16,610
‫Jadi pada dasarnya, masuk ke aplikasi Anda, oke?

202
00:09:16,610 --> 00:09:18,620
‫Tapi itu, tentu saja, topik untuk banyak kemudian.

203
00:09:18,620 --> 00:09:21,670
‫Jadi ini adalah lima metode HTTP

204
00:09:21,670 --> 00:09:24,349
‫yang dapat dan harus kita

205
00:09:24,349 --> 00:09:27,080
‫tanggapi saat membangun RESTful API

206
00:09:27,080 --> 00:09:29,320
‫sehingga klien dapat

207
00:09:29,320 --> 00:09:31,570
‫melakukan empat operasi CRUD dasar.

208
00:09:31,570 --> 00:09:33,270
‫Jadi CRUD adalah singkatan dari Create, Read, Update dan Delete.

209
00:09:33,270 --> 00:09:36,290
‫Dan Anda akan melihat istilah ini

210
00:09:36,290 --> 00:09:40,730
‫sepanjang waktu terkait dengan API dan hal-hal basis data.

211
00:09:40,730 --> 00:09:42,590
‫Dan Anda melihat bahwa metode HTTP

212
00:09:42,590 --> 00:09:45,200
‫ini memetakan dengan cukup baik ke operasi CRUD dasar.

213
00:09:45,200 --> 00:09:47,490
‫Sekarang, mungkin ada tindakan

214
00:09:47,490 --> 00:09:51,330
‫yang bukan CRUD, dan dalam hal ini, kita

215
00:09:51,330 --> 00:09:54,410
‫hanya perlu berkreasi dengan input kita.

216
00:09:54,410 --> 00:09:55,460
‫Misalnya, operasi masuk

217
00:09:55,460 --> 00:09:58,120
‫atau pencarian, ini tidak benar-benar terkait dengan

218
00:09:58,120 --> 00:09:58,953
‫sumber

219
00:09:58,953 --> 00:10:01,010
‫daya tertentu dan juga bukan operasi

220
00:10:01,010 --> 00:10:04,361
‫CRUD, tetapi kita masih dapat membuat titik akhir untuknya.

221
00:10:04,361 --> 00:10:06,630
‫Misalnya, seperti /login atau /search.

222
00:10:06,630 --> 00:10:09,240
‫Tetapi kita akan berbicara lebih banyak tentang kasus-kasus ini nanti dalam praktik.

223
00:10:09,240 --> 00:10:12,530
‫Dan hanya untuk menyelesaikan bagian ini sekarang, ingat

224
00:10:12,530 --> 00:10:16,350
‫bahwa kita memiliki dua nama titik akhir gila lainnya di

225
00:10:16,350 --> 00:10:18,290
‫slide terakhir yang melibatkan

226
00:10:18,290 --> 00:10:21,330
‫dua sumber daya pada saat yang sama, bukan?

227
00:10:21,330 --> 00:10:23,870
‫Dan itu juga tidak masalah sama sekali dengan REST.

228
00:10:23,870 --> 00:10:26,780
‫Jadi, /getToursByUser dapat

229
00:10:26,780 --> 00:10:29,888
‫dengan mudah diterjemahkan ke /users/tours,

230
00:10:29,888 --> 00:10:33,810
‫dalam hal ini, pengguna nomor tiga.

231
00:10:33,810 --> 00:10:36,210
‫Jadi titik akhir khusus ini di sini dapat

232
00:10:36,210 --> 00:10:38,440
‫mengirim data tentang semua tur yang telah

233
00:10:38,440 --> 00:10:40,200
‫dipesan oleh pengguna nomor tiga.

234
00:10:40,200 --> 00:10:42,340
‫Masuk akal?

235
00:10:42,340 --> 00:10:44,580
‫Atau dalam kasus penghapusan, mungkin ada

236
00:10:44,580 --> 00:10:45,519
‫permintaan penghapusan

237
00:10:45,519 --> 00:10:47,470
‫ke titik akhir yang sama atau

238
00:10:47,470 --> 00:10:50,170
‫sangat mirip, meminta tur nomor sembilan dihapus dari

239
00:10:50,170 --> 00:10:51,910
‫pengguna nomor tiga, oke?

240
00:10:51,910 --> 00:10:54,440
‫Jadi sebenarnya ada banyak sekali

241
00:10:54,440 --> 00:10:57,330
‫kemungkinan untuk menggabungkan sumber daya seperti ini.

242
00:10:57,330 --> 00:11:00,160
‫Tapi tentu saja, kita tidak harus mengimplementasikan semua

243
00:11:00,160 --> 00:11:02,470
‫kombinasi ini di API kita.

244
00:11:02,470 --> 00:11:04,260
‫Kami hanya mengimplementasikan apa

245
00:11:04,260 --> 00:11:06,600
‫yang masuk akal dalam kasus aplikasi kami dan

246
00:11:06,600 --> 00:11:08,400
‫klien yang ingin menggunakan API kami.

247
00:11:08,400 --> 00:11:10,090
‫Jadi, inilah cara kami

248
00:11:10,090 --> 00:11:13,203
‫menggunakan metode HTTP untuk membangun URL yang ramah pengguna

249
00:11:13,203 --> 00:11:17,480
‫dan terstruktur dengan baik yang mudah dan logis untuk dikonsumsi oleh klien.

250
00:11:17,480 --> 00:11:20,823
‫Sekarang, tentang data yang sebenarnya diterima klien,

251
00:11:20,823 --> 00:11:24,145
‫atau yang diterima server dari

252
00:11:24,145 --> 00:11:27,800
‫klien, biasanya kami menggunakan Format Data JSON.

253
00:11:27,800 --> 00:11:30,610
‫Jadi mari kita pelajari secara singkat apa itu JSON

254
00:11:30,610 --> 00:11:33,203
‫sebenarnya dan bagaimana memformat respons API kita.

255
00:11:34,440 --> 00:11:37,400
‫JSON adalah format pertukaran data yang sangat

256
00:11:37,400 --> 00:11:39,530
‫ringan yang banyak digunakan

257
00:11:39,530 --> 00:11:43,780
‫oleh API web yang dikodekan dalam bahasa pemrograman apa pun.

258
00:11:43,780 --> 00:11:46,220
‫Jadi itu tidak terkait dengan JavaScript.

259
00:11:46,220 --> 00:11:48,160
‫Dan itu sangat banyak digunakan saat

260
00:11:48,160 --> 00:11:50,740
‫ini karena sangat mudah bagi manusia dan komputer

261
00:11:50,740 --> 00:11:52,620
‫untuk memahami dan menulis JSON.

262
00:11:52,620 --> 00:11:55,930
‫Jadi Anda mungkin sudah memperhatikan bahwa JSON terlihat seperti

263
00:11:55,930 --> 00:11:57,990
‫objek JavaScript biasa, bukan?

264
00:11:57,990 --> 00:12:00,510
‫Dengan semua pasangan nilai kunci ini.

265
00:12:00,510 --> 00:12:04,020
‫Namun, ada beberapa perbedaan, dan yang paling

266
00:12:04,020 --> 00:12:06,470
‫penting adalah bahwa semua kunci

267
00:12:06,470 --> 00:12:08,320
‫harus berupa string.

268
00:12:08,320 --> 00:12:10,960
‫Ini juga sangat khas untuk nilai menjadi string

269
00:12:10,960 --> 00:12:12,580
‫juga tetapi mereka bisa

270
00:12:12,580 --> 00:12:14,730
‫menjadi hal-hal lain seperti angka, nilai benar

271
00:12:14,730 --> 00:12:17,440
‫atau salah, objek lain, atau bahkan array nilai lain.

272
00:12:17,440 --> 00:12:20,690
‫Ini cukup lurus ke depan, sebenarnya.

273
00:12:20,690 --> 00:12:23,328
‫Dan dari contoh ini, Anda dapat melihat

274
00:12:23,328 --> 00:12:25,790
‫seperti apa tampilan JSON yang khas.

275
00:12:25,790 --> 00:12:27,070
‫Katakanlah ini adalah

276
00:12:27,070 --> 00:12:30,883
‫data yang kami miliki di database kami untuk permintaan

277
00:12:31,890 --> 00:12:35,290
‫GET ke URL ini sehingga tur dengan I. D. dari lima.

278
00:12:35,290 --> 00:12:38,560
‫Sekarang, kami dapat mengirimkannya kembali seperti ini ke klien,

279
00:12:38,560 --> 00:12:41,440
‫tetapi kami

280
00:12:41,440 --> 00:12:44,300
‫biasanya melakukan beberapa pemformatan respons sederhana sebelum mengirim.

281
00:12:44,300 --> 00:12:47,130
‫Ada beberapa standar untuk ini dan kita akan menggunakan yang

282
00:12:47,130 --> 00:12:48,620
‫sangat sederhana yang disebut Jsend.

283
00:12:48,620 --> 00:12:50,880
‫Kami cukup membuat objek baru,

284
00:12:50,880 --> 00:12:54,570
‫lalu menambahkan pesan status ke dalamnya untuk memberi tahu klien

285
00:12:54,570 --> 00:12:56,320
‫apakah permintaan itu

286
00:12:56,320 --> 00:12:58,310
‫berhasil, gagal atau salah, dan

287
00:12:58,310 --> 00:13:00,740
‫kemudian kami memasukkan data asli kami

288
00:13:00,740 --> 00:13:03,350
‫ke objek baru yang disebut Data, oke?

289
00:13:03,350 --> 00:13:05,390
‫Dan kami dapat mengembangkan

290
00:13:05,390 --> 00:13:08,510
‫ini lebih jauh lagi tetapi ini adalah cara

291
00:13:08,510 --> 00:13:10,640
‫paling sederhana untuk memformat dengan Jsend.

292
00:13:10,640 --> 00:13:12,020
‫Dan omong-omong, membungkus data

293
00:13:12,020 --> 00:13:14,250
‫menjadi objek tambahan seperti yang kita lakukan

294
00:13:14,250 --> 00:13:15,240
‫di sini

295
00:13:15,240 --> 00:13:17,550
‫disebut Enveloping, dan itu adalah praktik umum untuk

296
00:13:17,550 --> 00:13:19,860
‫mengurangi beberapa masalah keamanan dan masalah lainnya.

297
00:13:19,860 --> 00:13:21,470
‫Selain itu, ada

298
00:13:21,470 --> 00:13:25,550
‫standar lain untuk pemformatan respons yang dapat Anda lihat, seperti Jsend:API

299
00:13:25,550 --> 00:13:27,200
‫atau Protokol JSON Odata.

300
00:13:27,200 --> 00:13:30,330
‫Baiklah, dan akhirnya,

301
00:13:30,330 --> 00:13:34,333
‫RESTful API harus selalu stateless.

302
00:13:35,800 --> 00:13:37,470
‫Jadi, apa sebenarnya yang dimaksud dengan stateless?

303
00:13:37,470 --> 00:13:40,720
‫Nah, dalam RESTful API stateless, semua

304
00:13:40,720 --> 00:13:43,170
‫status ditangani di

305
00:13:43,170 --> 00:13:45,960
‫klien dan bukan di server.

306
00:13:45,960 --> 00:13:48,410
‫Dan status hanya mengacu pada sepotong data dalam aplikasi

307
00:13:48,410 --> 00:13:50,120
‫yang mungkin berubah seiring waktu.

308
00:13:50,120 --> 00:13:52,910
‫Misalnya, apakah pengguna tertentu masuk atau

309
00:13:52,910 --> 00:13:55,750
‫di halaman dengan daftar dengan beberapa

310
00:13:55,750 --> 00:13:56,583
‫halaman,

311
00:13:56,583 --> 00:13:58,720
‫apa halaman saat ini.

312
00:13:58,720 --> 00:14:02,230
‫Sekarang fakta bahwa status harus ditangani pada klien

313
00:14:02,230 --> 00:14:04,150
‫berarti bahwa setiap

314
00:14:04,150 --> 00:14:06,170
‫permintaan harus berisi semua informasi

315
00:14:06,170 --> 00:14:09,910
‫yang diperlukan untuk memproses permintaan tertentu di server, oke?

316
00:14:09,910 --> 00:14:12,710
‫Apakah itu masuk akal?

317
00:14:12,710 --> 00:14:15,780
‫Jadi, server seharusnya tidak perlu

318
00:14:15,780 --> 00:14:17,170
‫mengingat

319
00:14:17,170 --> 00:14:21,030
‫permintaan sebelumnya untuk memproses permintaan saat ini.

320
00:14:21,030 --> 00:14:24,010
‫Mari kita ambil daftar dengan beberapa halaman sebagai contoh.

321
00:14:24,010 --> 00:14:25,906
‫Dan katakanlah berulang-ulang di

322
00:14:25,906 --> 00:14:29,670
‫halaman lima dan ingin maju ke halaman enam.

323
00:14:29,670 --> 00:14:32,980
‫Jadi kita bisa memiliki titik akhir sederhana yang disebut

324
00:14:32,980 --> 00:14:36,006
‫/tours/nextPage dan mengirimkan permintaan ke sana, bukan?

325
00:14:36,006 --> 00:14:39,710
‫Tetapi server kemudian harus mencari tahu apa halaman

326
00:14:40,650 --> 00:14:43,400
‫saat ini dan berdasarkan itu mengirim

327
00:14:43,400 --> 00:14:45,610
‫halaman berikutnya ke klien.

328
00:14:45,610 --> 00:14:48,450
‫Dengan kata lain, server harus

329
00:14:48,450 --> 00:14:50,496
‫mengingat permintaan sebelumnya.

330
00:14:50,496 --> 00:14:51,730
‫Itu harus

331
00:14:51,730 --> 00:14:54,950
‫menangani sisi server negara bagian dan itulah yang

332
00:14:54,950 --> 00:14:57,640
‫ingin kita hindari di RESTful API, oke?

333
00:14:57,640 --> 00:15:00,260
‫Sebagai gantinya, dalam kasus ini, kita

334
00:15:00,260 --> 00:15:03,120
‫harus membuat titik akhir /tours/page dan menempelkan

335
00:15:03,120 --> 00:15:04,630
‫nomor enam

336
00:15:04,630 --> 00:15:07,550
‫ke sana untuk meminta nomor halaman enam.

337
00:15:07,550 --> 00:15:09,410
‫Dengan cara ini, kami kemudian akan

338
00:15:09,410 --> 00:15:11,850
‫menyatakan pada klien karena pada klien, kami sudah

339
00:15:11,850 --> 00:15:14,340
‫tahu bahwa kami berada di halaman lima dan jadi

340
00:15:14,340 --> 00:15:15,410
‫yang harus kami

341
00:15:15,410 --> 00:15:18,320
‫lakukan hanyalah menambahkan satu dan kemudian meminta nomor halaman enam.

342
00:15:18,320 --> 00:15:20,750
‫Jadi server tidak perlu mengingat apa

343
00:15:20,750 --> 00:15:22,750
‫pun dalam kasus ini.

344
00:15:22,750 --> 00:15:23,920
‫Yang harus dilakukan adalah mengirim

345
00:15:23,920 --> 00:15:25,840
‫kembali data untuk halaman nomor enam seperti yang kami minta.

346
00:15:25,840 --> 00:15:27,940
‫Dan omong-omong, statelessness dan statefulness,

347
00:15:27,940 --> 00:15:30,840
‫yang merupakan kebalikannya, adalah konsep yang

348
00:15:30,840 --> 00:15:33,891
‫sangat penting dalam ilmu komputer dan desain

349
00:15:33,891 --> 00:15:35,760
‫aplikasi secara umum.

350
00:15:35,760 --> 00:15:38,560
‫Jadi, ada baiknya untuk benar-benar memahami apa itu

351
00:15:38,560 --> 00:15:40,800
‫API stateless dan cara kerjanya.

352
00:15:40,800 --> 00:15:44,070
‫Bagaimanapun, ini adalah kuliah besar, tetapi juga

353
00:15:44,070 --> 00:15:47,331
‫salah satu yang paling penting.

354
00:15:47,331 --> 00:15:50,280
‫Saya tidak bisa cukup menekankan itu dan saya benar-benar

355
00:15:50,280 --> 00:15:52,670
‫berpikir bahwa Anda dapat melihatnya, bukan?

356
00:15:52,670 --> 00:15:55,700
‫Bagaimanapun, sekarang mari kita kembali ke kode kita.