baya vdnz arn yi aldracaksiniz illa. ben binanceden basit yelik aldim sadece mail onayli. biraz aktarip alayim diyorum sorun olur mu daha sonra ekmesi kimliknonay yaptirmadan
GT-I9500 cihazmdan hisse.net mobile app kullanarak gnderildi.
ye
baya vdnz arn yi aldracaksiniz illa. ben binanceden basit yelik aldim sadece mail onayli. biraz aktarip alayim diyorum sorun olur mu daha sonra ekmesi kimliknonay yaptirmadan
GT-I9500 cihazmdan hisse.net mobile app kullanarak gnderildi.
Sadk ye
almanz iin bir ey yapmadk..aman yanl anlalmasn..kendimizce gzel grdmz yanlar yazdk paylatk forum gereince...karar sizin..illaki....Originally Posted by okan20
ye
tabiki sayn krokodil herkesin kendin karar sanuta. bizlerinki sadece bilgi paylaimi devamni bekliyoruz
GT-I9500 cihazmdan hisse.net mobile app kullanarak gnderildi.
ye
bu lunyr in dusmeye hic niyeti yok...0.004 bitcoini kirmaya kararli gibi....
Sadk ye
baktm bi inceledim kendimce bunu alacama neblio alrm..projesi heyacanlandrmad beni...bitrex de de ilem gryor ve token says olduka az..yaknda neblioda bitrex de ilem grecek..ilk eyrekde RESTful API uygulamas denenecek..neblio yeni neo olabilir..
Sadk ye
REST ve RESTful Web Servis Kavram
Merhaba,
Bir sredir, RESTful Web Service olayna merak sarm durumdaym. Modern Web mimarilerinde RESTful servisler ok yaygn bir ekilde kullanlyor. Olduka hafif, geniletilebilir, basit servisler. Artk SOA kullanlan projelerde de sklkla grlyor. REST aslnda uzun zamandr hayatmzda. Microsoft .Net Framework’e gelitirmeler yaparak istikrarl bir ekilde REST’e yatarm yapyor. Hatrlarsanz nce WCF’e REST mimarisi kullanan servisler gelitirmemize olanak salayan bir yap geldi. Hatta en son WCF Web API isim deitirerek ASP.NET Web API oldu, uan beta srecinde. Eski tarz servis uygulamalar giderek yerlerini REST tabanl uygulamalara brakyorlar, bunun en byk sebeplerinden biride gnmz uygulamalarnn artk ounlukla Browser tabanl olmas ve ou iin artk Client-Side’da yaplmas, REST’in HTTP’i protokol zerine kurulmu olmas bu adan ok byk nimet, hayatmz olduka kolaylatryor.
Aslnda ASP.NET Web API zerine bireyler yazmak istiyordum ama aratrma yaparken yine konunun derinliklerinde kayboldum ve kendimi REST konusunu aratrrken buldum
Daha ncede bahsettiim gibi blog yazmann en gzel yanlarndan biriside kendinizi gelitiriyor olmanz. Bende birok farkl kaynaktan edindiim bilgileri toparlayarak, REST hakknda fikir sahibi olmanz asndan byle bir yaz hazrlamaya karar verdim. REST kavramn anlamanz asndan yararl olacan dnyorum.
REST (REpresentational State Transfer)
REST client-server iletiimiyle ilgili bir mimari. HTTP protokol’ ile paralel olarak gelimi olmasnn yani sra bugn en ok hepimizin aina olduu World Wide Web sisteminde kullanlyor. REST mimarisini kullanan servislere genel olarak RESTful servis deniyor. Ana fikir aslnda client-server arasnda ki veri alveriini SOAP, RPC gibi kompleks mimarilerle salamak yerine, HTTP protokol zerinden salamak. nk zaten World Wide Web dediimiz yap HTTP protokol zerine kurulu. RESTful servisler SOAP, RPC’nin aksine basit ve hafiftirler.
Basit olmalarnn yannda olduka da esnek ve yeteneklidirler. Aslnda tipik Web Servislerle yapabileceiniz hereyi RESTful servislerle yapabilirsiniz. Ayrca mimari olarak nasl olmas, ne gibi zelliklere sahip olmas hakknda belli ynergeler olsa da, burada SOAP gibi keskin standartlar olan bir mimariden bahsetmiyoruz. zerine ou platformda (C#,JAVA vs.), bir sr Framework yazllm durumda, fakat birok platformun standart library’leri kullanlarak, kendimiz de hzlca REstful Servisler gelitirebiliriz. REST Mimarisi ve LEGO arasnda bir takm benzerlikler var aslnda, birazdan aklayacam
SOAP ile en byk fark, SOAP gibi bizi proxy kullanmaya, bir WSDL’e zorlamyor olmas (tamam teorik olarak sizde WSDL importer’lar proxy generator’lar kullanmak zorunda deilsiniz, kendiniz de yapabilirsiniz). Bunun avantajlar ve dezavantajlar var tabiki.
REST mimarisindeki nemli noktalardan biride her HTTP request’inde yaplmas istenilen ilemin HTTP Method’laryla (Verb) ifade edilmesi. POST, PUT, DELETE ,GET gibi. Bylece proxy ihtiyac ortadan kalkm oluyor ve platform bamsz yaplar kurmak kolaylayor. uanki modern uygulamalarda bu Method’lar harfiyen kullanmak bir zorunluluk olmasa da, standartlara uymak, ilem tutartll ve gvenlii asndan nemli. Bu Method’larn zerinden yaznn ilerleyen blmlerinde geeceim.
RESTful servisler’in birok farkl response tipi olabilir. Bugnlerde popler olarak JSON kullanlyor fakat XML, CSV veya amaca bal olarak HMTL bile kullanlabilir. lgin olan, nceki yllarda bandwith dk olmasna ramen SOAP tabanl servisler kullanarak kocaman kocaman verileri XML gibi verinin boyutunu daha da iiren yntemlerle aktaryorduk. uan bandwith inanlmaz boyutlara ulam durumda ve biz veri transferinde verinin boyutunu XML’e gre inanlmaz klten JSON kullanyoruz, hem de JSON yllardan beri varolmasna ramen. Neyse
SOAP’n aksine RESTful servislerin response’lar insan tarafndan daha rahat anlalabilirler.
Bugn birok irket RESTful servisleri kullanyor ;
Twitter’n, Facebook’un Rest API’si var.
Google’un, Amazon’un, Azure’un eitle amalarla kullanlabilecek bir sr REST servisi var.
Dnyann en nl oyun firmalarndan Blizzard Word of Warcraf oyuncularna karakterleri ile ilgili bilgileri RESTful servisler araclyla sunuyor. Hatta yaknda Diablo 3'de benzer bir API gelicek.
Eve Online’n da benzer bir REST API’si var.
Rest servisler ;
Platform bamszlar. (Client’n Windows, Server’n Linux olmasnn hi bir nemi yok)
Dil bamszlar .
HTTP zerinden alyorlar.
Esnekler ve ok kolay geniletilebilirler.
Ayrca belli kstlar da var ;
Bunlara ksttan daha ok REST mimarisinin hangi snrlar ierisinde yer almasn belirleyen prensipler diyebiliriz.
Kstlar
Clint-Server Mimarisi : Burada anlatlmak istenilen aslnda Separation of Concerns prensibi. Client’n Server tarafndaki veri kayna hakknda hi birey bilmemesi, Server’n da doru istekler geldii srece doru yant vermesi. Client ile Server’n birbirlerinden bamsz olmas. Ama aslnda platform bamsz almay ve scalability’i arttrmak. Ayrca aralarnda ki interface ortak kald srece birbirlerinden bamsz bir ekilde gelimeleri de salanm oluyor.
Stateless : Server tarafnda client ile ilgili bir context veya Session tutulmaz. Client tarafndan yaplan her request Server’n response verebilmesi iin gerekli bilgiyi tar, yani her trl state client tarafnda tutulur, ihtiya duyulursa request ierisinde server’a bildirilir. Bu Scalability asndan da nemlidir, nk server’n requestler arasnda herhangi bir state’i saklamasn gereksiz klar ve kaynak ynetimini kolaylatrr. Visibility asndan nemlidir, nk request’in amacn anlamak iin tek bir request’in ierdii bilgiler yeterlidir.
Tabi stateless olmasnn baz dezavantajlarda var. Client her request’de gerekli bilgileri eklemek zorundadr bu da network trafiini arttrr. Bu ayrca server’n uygulamann davranlarndaki tutarl kontrol etmesini zorlatrr, nk birok farkl client’dan farkl ierikli requestler gelebilir, server’a validasyon asndan daha fazla yk binebilir.
Cacheable : HTTP response’lar client tarafndan “cache”lenebilir, o yzden Server gnderdii response’larn cacheable olup olmadn belirtmek durumundadr, bu performans asndan nemlidir.
Uniform Interface : Client-Server’lar arasnda ortak, tekbiimli arayzlerin olmas REST’in en nemli prensiplerinden biridir. Bu hem iletiim yntemini basitletiriyor hem de ortak bir interface olmas sayesinde her parann birbirinden bamsz bir ekilde evrimlemesine olanak salyor. Bu konu daha nce bahsettiim HTTP Methodlar ilede alakal.
Bununla ilgili ok gzel bir rnek var, yukarda LEGO’dan bahsetmitim. LEGO ile oynayanlar bilirler, birbirinden farkl LEGO paralar olsa da, onlar birletirmenin sadece birka yolu vardr, herhangi bir alveri mazasndan aldnz yeni LEGO paras, elinizdeki paralarla kolay bir ekilde entegre olur, nk zaten standartlar nceden tanmlanmtr. Aklnza “LEGO paralarnn birbirlerine balamann bu kadar az yolu varken ortaya byk eyler kabilir mi?” gibisinden bir soru gelebilir. Sorunuzun cevabn buradan alabilirsiniz
Layered System : Burada kast edilen aslnda client’n son server’a m yoksa bir arac server’a m balandn bilmiyor olmas, yani her katman aslnda tek bir katman biliyor. Bu tr bir yapya olanak salamasyla birlekte, arac serverlar load-balancing yaparak scalability arttrabiliyor ve client’lar belli security policy’lerine zorlayabiliyorlar. Bu yap ayrca encapsulation yaplmas gereken yerlerde kullanlabiliyorlar.
Tabi byle bir pipe-line’n ar kullanm client — server arasnda gecikmelere sebep olabiliyor.
Code on Demand : Server belli durumlar’da client tarafndaki fonksiyonaliteyi arttrmak veya deitirmek iin, client tarafna executable scriptler gnderebilir. Byle bir kullanm baz durumlarda Visibility’i drd iin, Code on Demand tek opsiyonel ksttr.
Eer bir servis Code on demand kst hari dier kstlar iermiyorsa tam olarak RESTful servis deildir. Bu kstlarn ou, bugnn modern programlama ortramlarnda endie edilmesi veya uygulanmas zor kstlar deiller. Ayrca bu kstlarn ou bize yabanc gelen kavramlar deiller, oumuz kendi mimarilerimizde de kullanmzdr. Bence zaten en dikkat edilmesi gereken kst REST’in Stateless olmas. REST’in hedefledikleri aslnda ; Scalability, Simplicity, Modifiability, Visibility, Portability ve Reliability. Yukardaki kstlara ne kadar uyarsanz, hedeflediklerini o kadar gerekletirmi olursunuz.
Resource ve URI
REST mimarisinin kalbinde Resouce kavram yatmaktadr. Resource kavram REST’e zel bir kavram deil, halihazrda Web Browser’larda kullanmaktayz. Resource’lar herey olabilir, entity, item veya darya amak istediiniz herhangi birey. REST resource’larn URI zerinden tanmlar, SOAP’daki gibi “GetProductName”, “GetProductPrice” gibi method’lar veya servisler zerinden iletiim kurulmaz. Mesela ;
/products/productname/25
/users/username/45
ve ya
/users/GetUser
/users/DeleteUser
gibi daha tandk gelen resource’larda oluturabilirsiniz.
Aslnda URI templateleri oluturuyorsunuz ;
weatherForecast/{state}/{city}
weatherForecast/{state}/{city}?date={date}
gibi. Hatta isterseniz ;
/products/productname/25?dataFormat=json gibi eyler yaparak verinin geri dn tipini de belirtebilirsiniz. Buna da Resource Representation deniyor, bir response’un nasl bir veri tipiyle dnd tamamen sizin tasarmnza kalm, isterseniz bir ok farkl tipi de destekleyebilirsiniz ya da sadece tek bir tip desteklersiniz. Yukarda HTTP Method’larndan bahsetmitim. Mesela /users/GetUser’a request’de bulunurken GET Method’u ile gitmek veya /users/DeleteUser DELETE Method’u ile gitmek salkl olur. Dediim gibi bununla ilgili daha detayl aklama yapacam.
Resource kavram REST’in kalbi, o yzden RESTful bir servis yazmadan nce mutlaka Resource’larnz tasarlayn.
HTTP Method’lar ve REST’de Kullanm
REST’deki en nemli konulardan biride HTTP Method’larn nasl kullanlmas gerektii mevzuu.
ncelikle Idempotent kavramndan bahsedilim. Matematik ve bilgisayar biliminde bir fonksiyonun bir defa uygulanmas ile birden fazla defa uygulanmas, sonucu deitirmiyor ise bu fonksiyon Idempotent’dir. HTTP methodlar arasnda GET, PUT, DELETE Idempotent methodlardr. POST deildir.
Bugn aslnda GET ve POST her iimizi gryor. Peki neden POST yerine PUT ve ya silmek iin ayriyetten DELETE method’larna da kullanmamz gerekiyor. Bunun birka sebebi olmasna ramen bu sebeplerin hi biri bizi PUT ve DELETE kullanmak zorunda brakan sebepler deil. Ama REST’in tek amac data’ya en basit ekilde ulamak deildir, REST ayn zamanda data’ya anlaml bir ekilde ulama metadolojisidir, bir request’e baktnz zaman onun ne i yaptn anlamanz nemlidir. Ayrca idempotency kavram da bu noktada nemli. Akla ilk gelicek sorulardan biri POST mu? PUT mu?
PUT ve POST arasndaki kavramsal farktan daha ncede bahsettik, PUT idempotent bir method, yani ayn Resource’a yaptnz ayn PUT request’ini bir veya birden fazla defa yapmanz sonucu deitirmez. Fakat POST ayn ey deil, o yzden browserlar bizi POST yaplan bir yerde refresh, back gibi eyler yaptmzda uyarr, nk server’da ilgili resource’un state’i deiebilir. Tamam uygulamay biz yazyoruz, requestleri karlayan bizleriz, POST’un da ayn davrann sergilmesini salayabiliriz fakat client asndan mesela browserlar asndan PUT ve POST arasnda ok fark var. Uniform Interface kstnda da aslnda kast edilen bu.
Demek istediim create ilemlerinde PUT kullann deil, kafanz karmasn, tam anlamyla gerektii yerde kullanmak lazm. Mesela ;
HTTP/1.1 PUT /DataStorage/Pictures/deniz.jpg
...
<deniz.jpg'in ierii ... >
eklinde bir request ile deniz.jpg adnda bir resource’u server’da yaratyoruz, bu request’i 100 kere de gndersek fark etmez nk hep deniz.jpg’yi gnderiyoruz. Btn content’i ayn spesifik bir Resource’a gnderiyoruz. Fakat ;
HTTP/1.1 POST /DataStorage/Pictures
…
<?xml version="1.0" encoding="UTF-8"?>
<DataStorage operation="add" type="jpeg">
<[CDATA[ <herhangi bir resmin ierii > ]]>
</DataStorage>
Farkl anladnz m? Eer bu request’i birden fazla tekrarlarsak, ayn content’e sahip 2 adet resim server tarafnda oluur. POST’un gc ve tehlikesi de bu, POST ile hereyi yapabilirsiniz, Create,Delete,Update hereyi.
Mesela tekrar bir rnek verelim. Bir forum siteniz var ve bir baln altna yorum eklemek istiyoruz, ilgili alanlar doldurduktan sonra POST ederiz, nk bu aamada bize PUT’daki gibi HTTP 200 (No error, operation successful.) response’u yetmez, nk ayn zamanda bir resource’da deiiklik yapyoruz ve yaptmz deiiklii grmek isteriz, o yzden ASP.NET’de Postback kavram vardr.
Aslnda zetle unu demek istiyorum ;
Create = Eer spesifik bir Resource’un btn bir ieriini gnderiyorsanz PUT kullann.
Create = Eer server’a spesifik bir Resource’a bal olan ierik gnderiyorsanz POST kullann.
Retrieve = GET.
Update = Eer spesifik bir Resource’un btn bir ieriini gnderiyorsanz PUT kullann.
Update = Eer spesifik bir Resource’a bal bir veya birden fazla ierik deitiriyorsanz POST kullann.
DELETE =
Ayrca bu method’larn response kod’larda client asndan byk nem tar, bu kodlar incelerseniz, nerede hangi Method’u kullanmanz gerektii kafanz daha iyi oturur.
REST konusunu aratrrken en ok takldm konulardan biri de nerede POST nerede PUT konusuydu. O yzden bu ksmn zerinde bu kadar ok durdum.
REST Mimarisinde Security
REST, SAOP veya RPC’de ki gibi hazr bir security yapsyla gelmiyor, aslnda bir security yapsda dayatmyor. Yine de kullanabileceiniz bir ok yntem sz konusu.
REST’in HTTP protokoln kullandndan bahsetmitik, HTTP’nin de kendine has Authentication mekanizmalar var, bunlar kullanmamz asndan hi bir engel yok. Mesela bunlardan en popleri Basic Access Authentication. Kullanmas ok kolay, fakat kesinlikle HTTPS ile beraber kullanlmas gerekiyor, nk ifreyi plain-text olarak gnderiyor, HTTPS ile kullandmz zaman encrypted olarak gnderebiliyoruz.
Dier alternatifimiz ise Digest Authentication, bu da HTTP’nin Authentication mekanizmalarndan birisi. Bu mimaride ifre plain-text olarak gnderilmek yerine, data’nn o ifre ile hash’i alnr yle gnderilir. Server gelen datann hash’ini ayn ifre tekrar alr ve hashleri karlatrr bylece datann valid bir yerden gelip gelmedini anlar. Tabi buradaki en nemli nokta client ile server’n ifreyi bilmesi gereklilii ki server’da ayn ifre ile hash alp karlatrma yapabilsin.
Olaylar u ekilde geliiyor, client server’a bir request’de bulunuyor ve server 401 (“Unauthorized”) response’unu dndrr. Client bu cevab aldktan sonra bunun Authorization gerektiren bir request olduunu anlar ve request’in Header’na Authorization datasn gmer (Hash’li data), server bu sefer istenilen yant verir. Basic Access Authentication’dan daha gvenli bir yntem olsa da hala brute force gibi saldrlara aktr ayrca btn server ve browser’lar tarafndan desteklenmemektedir.
Tabi tek seeneimiz HTTP’nin bize salad gvenlik mekanizmalar deil hata gnmzde ounlukla RESTful servislerde HMAC (Hash Message Authentication Code) yntemini kullanlyor. Aslnda bu costum bir yap, digest’deki gibi “Authorization” header zerinden security bilgilerini yolluyoruz. Olay u ;
Server client’a bir ekilde userId ve secret key salyor. Nasl saladnn hi bir nemi yok, bu konuyu aratrken en ok bu noktaya taklmtm, siz taklmayn. Yani adam bir ekilde bir yere user id ile kayt olur oradan alr veya email ile kendisine gelir veya normal postayla. nemli olan Server'n Client'a bu bilgiyi salam olmas ve kendi tarafnda user ile ilikili olarak bu key'i tutuyor olmas.
Client bu aamadan sonra btn requestlerini bu userid ve key ile imzalayp yle gnderirir. Burada dikkat edilmesi gereken nokta Server’n Client’a request’in hangi ksmnlarn, hangi algoritma ile imzalayacan bildirmesi gereklilii. nk client her request’de kendisine verilen algoritmayla HMAC Hash’ini retip, userid’si ile beraber “Authorization” header’na gmmeli.
Authorization: dirgin:uBMfGaLjue+TSDygYB5aEg==
Server request’i aldktan sonra “Authorization” header’ alp split eder ve gelen userid’nin kendi tarafnda kaytl olan key’ini bulur, ardndan request’deki ilgili alanlarn HMAC Hash’ini bu key ile tekrar alr ve kendisine gelen Hash ile karlatrr. Eer hash’ler aynysa kullancnn yetkili bir kullanc olduu anlalp doru response dnlr.
HMAC yaklam Basic Access Authentication ve Digest Authentication’a gre daha etkili bir yaklam verilen key random ve yeterince uzunsa brute force saldrlarna karda etkili. Ayrca paranoyak olmanz gerektiren bir durum varsa kullanclara verilen keylerin belli bir sre sonra expire olmasn salayabilirsiniz bylece kullanc belli aralklarla yeniden bir key edinmek durumunda kalr. Bu yaklam RESTful servislerde en ok kullanlan yaklam.
REST vs SOAP
Bu kadar REST anlattktan sonra insann aklna SOAP m? REST mi? sorusu geliyor elbette
Bana sorarsanz bir Web Servis tasarlarken nce REST’i deneyin, (yapamadnz eyler olursa ki bu durumlar ok az) SOAP’ deneyin. Bu aamada karlatrmal gitmekte yarar var.
REST’in avantajlar nelerdir ;
Hafiftir, kolay extend edilebilir.
Gelen, giden data boyutu SOAP ile karllatrldnda ok ufaktr
Tasarlamas kolaydr ve implementasyonu kolaydr, herhangi bir ekstra tool’a ihtiyac yoktur
HTTP zerinden alr, platform bamszdr
SOAP’n avantajlar ;
Consume etmesi kolaydr, bir emayla beraber gelir
Type-safety’dir, sizi bu tr validasyonlarla uratrmaz
Bir sr development tool’u vardr
Security implementasyonu REST’e gre daha kolaydr, bir sr hazr yap vardr.
En genel manada ikisinin de avantajlar bunlar. Benim grm enterprise uygulamalarda SOAP daha kolay bir zm olabiliyor. Onun haricinde dediim gibi SOAP ile yappta REST ile yapamayacanz hi birey yok. O yzden nce REST’i deneyin her zaman.
Evet bylece bir yazmzn daha sonuna gelmi olduk, umarm REST kavram kafanzda oturmutur. Soru, grlerinizi her zaman bildirebilirsiniz.
Bir sonraki yazmda grnceye dek hepinize iyilikler dilerim...
Deniz rgin Blog dan alntdr...
Sadk ye
enfakturs hoca gelmi...ho gelmi..hocam affnza snyorum..
Kdemli ye
arkadaslar bu linkten 15 bedava lino token kazanma sansiniz var.kazanin ve kazandirin.
https://drop.lino.network?code=YMO8r6nq
bunuda kacirmayin millet, madem tokenler beles oraya yerles
http://vy.tc/eg1CN49
Son dzenleme : Yatirimciali; 29-01-2018 saat: 07:42.
Dolar pacavrasida, onu matbaada basip dunyayi kendine kole eden sahibide batacak, biz dimdik duracagiz.
Gnderi Kurallar
Yer mleri