[]
JavaScript API's nispeten zor bir konu mudur?
Gençler selâm,
İki buçuk aydır JavaScript çalışıyorum. Yol haritamın sonlarına geldim. Çok iyi kavrayamadığım birkaç konu oldu ama en çok API'larda zorlandım. Tutorialleri izleyip postman kullanmayı, key almayı, endpoint noktalarını vs. yapabiliyorum ama neden böyle yapıyoruz hiçbir fikrim yok. Baktığım videolarda genelde openweathermap'le hava durumu yapıyorlar ama kafam durdu sanırım, hiçbir şey anlamıyorum.
YouTube'daki videolara, dokümanlara bakınca iyice aklım karışıyor. Zaman zaman böyle zorluklar yaşadığım oldu. Molasız, çok uzun süredir yüksek tempoyla çalıştığım için bunları yaşamam normal. Muhtemelen biraz dinlendikten sonra sağlam kafayla çalıştığımda kavrarım ama yine de sizlerin tavsiyesini almak istedim.
Bu API mevzusunu anlamak zor mu?
İyice kavramam için ne tavsiye edersiniz?
Şu dokümanı, videoyu ısrarla izle anlarsın dediğiniz bir kaynak var mı? Muhtemelen atacağınız kaynağa bakmış olacağım ama en azından daha çok zorlarım kendimi. :D
"Bu soruyu google'a soramıyorsan, nasıl yazılımcı olacaksın?" demeyin, çünkü hata kodlarını aratmayı, stackoverflow kullanmayı öğrendim. Daha spesifik tavsiyeler arıyorum.
İki buçuk aydır JavaScript çalışıyorum. Yol haritamın sonlarına geldim. Çok iyi kavrayamadığım birkaç konu oldu ama en çok API'larda zorlandım. Tutorialleri izleyip postman kullanmayı, key almayı, endpoint noktalarını vs. yapabiliyorum ama neden böyle yapıyoruz hiçbir fikrim yok. Baktığım videolarda genelde openweathermap'le hava durumu yapıyorlar ama kafam durdu sanırım, hiçbir şey anlamıyorum.
YouTube'daki videolara, dokümanlara bakınca iyice aklım karışıyor. Zaman zaman böyle zorluklar yaşadığım oldu. Molasız, çok uzun süredir yüksek tempoyla çalıştığım için bunları yaşamam normal. Muhtemelen biraz dinlendikten sonra sağlam kafayla çalıştığımda kavrarım ama yine de sizlerin tavsiyesini almak istedim.
Bu API mevzusunu anlamak zor mu?
İyice kavramam için ne tavsiye edersiniz?
Şu dokümanı, videoyu ısrarla izle anlarsın dediğiniz bir kaynak var mı? Muhtemelen atacağınız kaynağa bakmış olacağım ama en azından daha çok zorlarım kendimi. :D
"Bu soruyu google'a soramıyorsan, nasıl yazılımcı olacaksın?" demeyin, çünkü hata kodlarını aratmayı, stackoverflow kullanmayı öğrendim. Daha spesifik tavsiyeler arıyorum.
merhaba,
API sizin kullandiginiz mimari icin, backend'in disariya acilan arayuzudur ( rest api ). Bahsettiginiz openweathermap insanlara havadurumu bilgisi sunuyor, bu bilginin mobile, web vs. internete acilan cesitli cihazlar tarafindan sorgulanmasi icin disariya guvenli, tutarli, stabil bir arayuz acmak zorunda. Bu arayuz sayesinden veriyi isteyecek olan client'lara kullandiginiz key ile authorization & authentication saglayabilir, kimin ne siklikla, ne kadar veri isteyebilecegini yonetebilir. Kisaca size bir anahtar verip, guvenli bir giris kapisi ( rest api ) sunuyor. Boyle yapmasaydi sistem uzerinde kendi kontrolunu saglayamazdi.
API genis bir kavramdir, sizin kullandiginizi tahmin ettigim, aciklamaya calistigim rest api ise http uzerinden calisan, en guncel/populer backend-client iletisim yontemlerinden birisidir. API kavraminin tamamini kapsamiyor yazdiklarim.
API sizin kullandiginiz mimari icin, backend'in disariya acilan arayuzudur ( rest api ). Bahsettiginiz openweathermap insanlara havadurumu bilgisi sunuyor, bu bilginin mobile, web vs. internete acilan cesitli cihazlar tarafindan sorgulanmasi icin disariya guvenli, tutarli, stabil bir arayuz acmak zorunda. Bu arayuz sayesinden veriyi isteyecek olan client'lara kullandiginiz key ile authorization & authentication saglayabilir, kimin ne siklikla, ne kadar veri isteyebilecegini yonetebilir. Kisaca size bir anahtar verip, guvenli bir giris kapisi ( rest api ) sunuyor. Boyle yapmasaydi sistem uzerinde kendi kontrolunu saglayamazdi.
API genis bir kavramdir, sizin kullandiginizi tahmin ettigim, aciklamaya calistigim rest api ise http uzerinden calisan, en guncel/populer backend-client iletisim yontemlerinden birisidir. API kavraminin tamamini kapsamiyor yazdiklarim.
- whisky
(11.07.22 17:26:25)
API'lar zor bi konu değil. Ama yabancı bişeyle karşılaşınca başta oturmaması normal bişey. Bana da sürekli oluyor.
Şimdi abi API aslında iki farklı programın birbiriyle iletişim kurabilmesi için tasarlanmış arayüzlerin genel adı. Sadece web/js değil, her yerde kullanılan bir kavram. Arayüz dediğimiz de görsel bir şey değil, kullanacakları "format"ın adı. İşte bi programın diğerine "bende şu şu fonksiyonlar var, şu isteği yaparsan böyle bi cevap alırsın" deme yöntemi yani.
Web özelinde durum şu: artık (mesela bir websitesinin) frontend ve backend kısımlarını ayrı ayrı programlar/projeler olarak yazıyorlar, çünkü iki taraf da çok karmaşıklaştı, tek kişi her şeyini öğrenemiyor. Dolayısıyla ortada birden çok uygulama olunca, bunların birbiriyle bi şekilde konuşması gerekiyor. Frontend dediğimiz senin tarayıcında çalışan kod, backend de sunucuda çalışan kod. Mobil uygulamalara da frontend deniyor, kabaca kullanıcının direkt kullandığı programlara deniyor.
Mesela:
1- sen bu duyuruyu kendi bilgisayarında tarayıcıda yazdın.
2- senin tarayıcında çalışan duyuru frontend uygulaması aldı senin sorunu, backend'in API'ına gönderdi ki backend alıp bunu sunucuya / database'e kaydedebilsin.
3- benim tarayıcımdaki frontend uygulaması da yine backend'e (API'a istek göndererek) "son duyuruları getir" dedi.
4- sunucuda çalışan backend uygulaması, son duyuruları database'den çekip frontend uygulamasına gönderdi, frontend uygulaması da onları böyle alt alta render etti, ben de senin duyurunu görmüş oldum.
5- şimdi ben de bu cevabı kendi tarayıcımda (frontend uygulamasında) yazıyorum. birazdan gönder tuşuna bastığımda bir API isteği ile backend'e kaydedilecek.
6- senin frontend'in backend'de yine API aracılığıyla "şu duyurunun cevaplarını göster" isteği attığında, bu cevabı görüyor olacaksın.
Bir de REST API dedikleri bir şey var, bu da web'e özelleşmiş bir API kurma yöntemi / formatı. JS'te başka bir sunucuya istek gönderirken GET, POST, DELETE falan gibi keyword'ler (verb deniyor bunlara) görmüşsündür. Bunlar çeşitli istek türleri.
Böyle bi standardın olma sebebi de işte millet birbirinin kodunu daha rahat anlasın, ona göre yeni programlar geliştirebilsin vs. diye.
Bunlar da kabaca şöyle:
GET -> frontend backend'den veri istiyor. Mesela son duyurular, duyuruların cevapları vs.
POST -> frontend backend'e yeni veri gönderiyor. İşte yeni duyuru gönderme, duyuruya cevap verme vs.
DELETE -> frontend, backend'den bir veriyi silmesini istiyor. Yazdığın cevabı silmek için mesela.
PUT / PATCH -> frontend, backend'e diyor ki abi sende bi veri var, al bunu yenisiyle değiştir. PUT tümden yeni veriyi yaz diyor, PATCH sadece bi kısmını güncelle diyor. Duyuru editleme de buna örnek.
Başka verb'ler de var, ama en yaygın kullanılanları bunlar.
Şimdi ben diyelim ekşi duyurunun backend'ini yeniden yazıyorum. İşte database şu bu hepsini yazdım, şimdi de API yazıp frontend'le konuşmasını sağlamam lazım. O zaman şöyle kod yazıyorum:
1- Frontend'den çok çeşitli istekler gelebilir (duyurular, cevaplar, mesajlar vs.), o yüzden bunlar için çeşitli "endpoint"'ler belirlemem lazım. Yani her kavram için bir url belirleyeyim ki, o url'lere istek geldiği zaman ona göre bir iş yapabileyim.
Mesela duyurular için:
eksiduyuru.com/duyuru
diye bir endpoint tanımladım. Yani birisi buraya bi istek gönderdiğinde, duyurularla ilgili bi işlem yapıcam.
2- Sonra da diyorum ki, bu endpoint'e eğer GET isteği gelirse, son duyuruları cevap olarak döneyim. Yok POST isteği gelirse, o zaman yeni bir duyuru oluşturayım.
eksiduyuru.com/duyuru/123
gibi de ekstra bir endpoint'im olsun. Burada 123 duyuru id'si. Buna GET isteği gelirse o duyuruyu database'den alıp frontend'e göndericem. DELETE isteği gelirse komple silicem database'den.
3- Bunları illa ki böyle endpoint'ler üzerinden yapmak zorunlu değil, API'ı istediğim gibi tanımlayabilirim, ama dediğim gibi bu yaygın bir yöntem. Çünkü herkes böyle yapığı için anlaması daha kolay.
Mesela tek bir endpoint'im olurdu:
eksiduyuru.com
Buna sadece POST isteği kabul ederim. POST isteğinin body'sinde de bi fonksiyon ismi isterim. fonksiyon ismi "duyuruSil" ve id=123 olursa 123 id'li duyuruyu silerim. Yani içerideki kod aynı, ama API kısmını böyle yazdım. Olur mu olur, eskiden böyle yazılıyordu zaten, ama artık REST standardı daha yaygın.
Şimdi abi API aslında iki farklı programın birbiriyle iletişim kurabilmesi için tasarlanmış arayüzlerin genel adı. Sadece web/js değil, her yerde kullanılan bir kavram. Arayüz dediğimiz de görsel bir şey değil, kullanacakları "format"ın adı. İşte bi programın diğerine "bende şu şu fonksiyonlar var, şu isteği yaparsan böyle bi cevap alırsın" deme yöntemi yani.
Web özelinde durum şu: artık (mesela bir websitesinin) frontend ve backend kısımlarını ayrı ayrı programlar/projeler olarak yazıyorlar, çünkü iki taraf da çok karmaşıklaştı, tek kişi her şeyini öğrenemiyor. Dolayısıyla ortada birden çok uygulama olunca, bunların birbiriyle bi şekilde konuşması gerekiyor. Frontend dediğimiz senin tarayıcında çalışan kod, backend de sunucuda çalışan kod. Mobil uygulamalara da frontend deniyor, kabaca kullanıcının direkt kullandığı programlara deniyor.
Mesela:
1- sen bu duyuruyu kendi bilgisayarında tarayıcıda yazdın.
2- senin tarayıcında çalışan duyuru frontend uygulaması aldı senin sorunu, backend'in API'ına gönderdi ki backend alıp bunu sunucuya / database'e kaydedebilsin.
3- benim tarayıcımdaki frontend uygulaması da yine backend'e (API'a istek göndererek) "son duyuruları getir" dedi.
4- sunucuda çalışan backend uygulaması, son duyuruları database'den çekip frontend uygulamasına gönderdi, frontend uygulaması da onları böyle alt alta render etti, ben de senin duyurunu görmüş oldum.
5- şimdi ben de bu cevabı kendi tarayıcımda (frontend uygulamasında) yazıyorum. birazdan gönder tuşuna bastığımda bir API isteği ile backend'e kaydedilecek.
6- senin frontend'in backend'de yine API aracılığıyla "şu duyurunun cevaplarını göster" isteği attığında, bu cevabı görüyor olacaksın.
Bir de REST API dedikleri bir şey var, bu da web'e özelleşmiş bir API kurma yöntemi / formatı. JS'te başka bir sunucuya istek gönderirken GET, POST, DELETE falan gibi keyword'ler (verb deniyor bunlara) görmüşsündür. Bunlar çeşitli istek türleri.
Böyle bi standardın olma sebebi de işte millet birbirinin kodunu daha rahat anlasın, ona göre yeni programlar geliştirebilsin vs. diye.
Bunlar da kabaca şöyle:
GET -> frontend backend'den veri istiyor. Mesela son duyurular, duyuruların cevapları vs.
POST -> frontend backend'e yeni veri gönderiyor. İşte yeni duyuru gönderme, duyuruya cevap verme vs.
DELETE -> frontend, backend'den bir veriyi silmesini istiyor. Yazdığın cevabı silmek için mesela.
PUT / PATCH -> frontend, backend'e diyor ki abi sende bi veri var, al bunu yenisiyle değiştir. PUT tümden yeni veriyi yaz diyor, PATCH sadece bi kısmını güncelle diyor. Duyuru editleme de buna örnek.
Başka verb'ler de var, ama en yaygın kullanılanları bunlar.
Şimdi ben diyelim ekşi duyurunun backend'ini yeniden yazıyorum. İşte database şu bu hepsini yazdım, şimdi de API yazıp frontend'le konuşmasını sağlamam lazım. O zaman şöyle kod yazıyorum:
1- Frontend'den çok çeşitli istekler gelebilir (duyurular, cevaplar, mesajlar vs.), o yüzden bunlar için çeşitli "endpoint"'ler belirlemem lazım. Yani her kavram için bir url belirleyeyim ki, o url'lere istek geldiği zaman ona göre bir iş yapabileyim.
Mesela duyurular için:
eksiduyuru.com/duyuru
diye bir endpoint tanımladım. Yani birisi buraya bi istek gönderdiğinde, duyurularla ilgili bi işlem yapıcam.
2- Sonra da diyorum ki, bu endpoint'e eğer GET isteği gelirse, son duyuruları cevap olarak döneyim. Yok POST isteği gelirse, o zaman yeni bir duyuru oluşturayım.
eksiduyuru.com/duyuru/123
gibi de ekstra bir endpoint'im olsun. Burada 123 duyuru id'si. Buna GET isteği gelirse o duyuruyu database'den alıp frontend'e göndericem. DELETE isteği gelirse komple silicem database'den.
3- Bunları illa ki böyle endpoint'ler üzerinden yapmak zorunlu değil, API'ı istediğim gibi tanımlayabilirim, ama dediğim gibi bu yaygın bir yöntem. Çünkü herkes böyle yapığı için anlaması daha kolay.
Mesela tek bir endpoint'im olurdu:
eksiduyuru.com
Buna sadece POST isteği kabul ederim. POST isteğinin body'sinde de bi fonksiyon ismi isterim. fonksiyon ismi "duyuruSil" ve id=123 olursa 123 id'li duyuruyu silerim. Yani içerideki kod aynı, ama API kısmını böyle yazdım. Olur mu olur, eskiden böyle yazılıyordu zaten, ama artık REST standardı daha yaygın.
- plutongezegendegilmi (11.07.22 17:31:31)
1
