• Sonuç bulunamadı

RESTFUL WEB SERVİSLERİ ÜZERİNE BİR İNCELEME

N/A
N/A
Protected

Academic year: 2022

Share "RESTFUL WEB SERVİSLERİ ÜZERİNE BİR İNCELEME"

Copied!
46
0
0

Yükleniyor.... (view fulltext now)

Tam metin

(1)

EGE ÜNİVERSİTESİ FEN BİLİMLERİ ENSTİTÜSÜ

(YÜKSEK LİSANS DÖNEM PROJESİ)

RESTFUL WEB SERVİSLERİ ÜZERİNE BİR İNCELEME

Özge ÖZKAYA

Proje Danışmanı: Yrd. Doç. Dr. Geylani KARDAŞ

Uluslararası Bilgisayar Anabilim Dalı

Bilim Dalı Kodu: 619.02.04 Sunuş Tarihi: 25.06.2013

Bornova-İZMİR 2013

(2)
(3)

Özge ÖZKAYA tarafından dönem projesi olarak sunulan “Restful Web Servisleri Üzerine Bir İnceleme” başlıklı bu çalışma E.Ü. Lisansüstü Eğitim ve Öğretim Yönetmeliği ile E.Ü. Fen Bilimleri Enstitüsü Eğitim ve Öğretim Yönergesi’nin ilgili hükümleri uyarınca tarafımızdan değerlendirilerek savunmaya değer bulunmuş ve 25/ 06 /2013 tarihinde yapılan proje savunma sınavında aday oybirliği ile başarılı bulunmuştur.

Jüri Üyeleri: İmza

Jüri Başkanı : Yrd. Doç. Dr. Geylani KARDAŞ Raportör Üye : Yrd. Doç. Dr. Müge SAYIT

Üye : Yrd. Doç. Dr. Orhan DAĞDEVİREN

(4)
(5)

ÖZET

RESTFUL WEB SERVİSLERİ ÜZERİNE BİR İNCELEME

ÖZKAYA, Özge

Yüksek Lisans Dönem Projesi, Uluslararası Bilgisayar Anabilim Dalı (TEZSİZ) Danışmanı: Yrd. Doç. Dr. Geylani KARDAŞ

Haziran 2013, 32 Sayfa

Günümüzde kullanıcılar arası işbirliği ve içerik paylaşım ihtiyacı ile birlikte gelişen teknoloji WWW (World Wide Web) dünyasında web tabanlı yazılımların geliştirilmeye başlanmasını sağlamıştır. Bu alanda, web üzerinden makineden makineye birlikte işleyebilen etkileşimli yazılımlar hazırlanırken Web Servisleri önemli bileşenlerinden biri olmuştur. Web servislerini geliştirmek için çoğunlukla Servis-Yönelimli Mimariler (SOA) kullanılmaktadır. Günümüzde de RPC, SOAP gibi karmaşık mimariler yerine basit ve hafif bir yapı olarak REST mimarisine dayanan Resftul web servislerinin hazırlanması giderek popülerleşmektedir.

Bu projede Web Servis kavramı ve Web Servis teknolojileri açıklanmıştır.

REST mimari yaklaşımından yola çıkarak Restful web servisleri hakkında bir inceleme yapılmış ve bir uygulaması gerçekleştirilerek bu mimariye dayalı servis geliştirme deneyimleri belgelendirilmiştir.

Anahtar Kelimeler: Web Servis, SOAP, Rest, Restful Web Servisi, Twitter, Google Map

(6)
(7)

ABSTRACT

A STUDY ON THE RESTFUL WEB SERVICES

ÖZKAYA, Özge

MSc in Computer Engineering

Supervisor: Asst. Prof. Dr. Geylani KARDAŞ Jun 2013, 32 Pages

Nowadays, collaboration and content sharing needs between users with evolving technology in WWW (World Wide Web) cause the development of web- based software. Within this context, Web service become one of the important components that support the construction of machine to machine interactive software over the web. Service-oriented architecture (SOA) is perhaps the most commonly used architecture in the development of Web services. Today, complex architectures such as the RPC, SOAP and etc. are replaced with REST which is getting popular in the simple and lightweigth use of web services.

The Web service concepts and Web service technologies are discussed in this project. Restful web services based on the REST architecture are described and the experience is documented with a sample web service application.

Keywords: Web Services, SOAP, Rest, Restful Web Services, Twitter, Google Maps

(8)
(9)

TEŞEKKÜR

Bu çalışmada, bilgi ve deneyimlerini benimle paylaşan proje danışmanım Yrd. Doç. Dr. Geylani Kardaş’a, çalışmam boyunca her türlü destek ve yardımlarıyla her zaman yanımda olan eşim ve arkadaşlarıma, eğitim hayatım boyunca her zaman yanımda olan ve büyük bir özveride bulunarak desteklerini esirgemeyen anne ve babama çok teşekkür ederim.

(10)
(11)

İÇİNDEKİLER

Sayfa

ÖZET ... v

ABSTRACT ... vii

TEŞEKKÜR ... ix

İÇİNDEKİLER ... xi

ŞEKİLLER DİZİNİ ... xii

1. GİRİŞ ... 1

2. ALTYAPI ... 3

2.1 Web Servisi ve Teknolojileri ... 3

2.1.1 Web Servis Modeli ... 3

2.1.2 Web Servis Teknolojileri ... 5

2.2 Restful Web Servisleri ... 8

2.2.1 Rest mimarisi ... 8

2.2.2 Restful web servisi ... 9

2.3 Twitter ... 11

2.4 Google Map ... 12

3 SİSTEM MİMARİSİ ... 13

3.1 Twitter Rest Api ... 13

3.1.1 Twitter search api ... 14

3.2 Google Map Api ... 16

3.3 Twitter Map Servisi ... 16

3.3.1 Uygulama arayüzü ... 17

4 ÖRNEK BİR UYGULAMA SENARYOSU ... 23

5 SONUÇ ... 28

KAYNAKLAR DİZİNİ ... 29

ÖZGEÇMİŞ ... 32

(12)

xii

ŞEKİLLER DİZİNİ

Şekil Sayfa

1.1 Uygulama entegrasyon stilleri ... 1

2.1 Web Servis mimari modeli ... 4

2.2 Web Servis çağırma aşaması ... 4

2.3 SOAP iletişim şeması ... 7

2.4 Restful Web Servis örneği ... 11

3.1 Sistem mimarisi ... 13

3.2 OAuth işleyişi ... 14

3.3 Twitter arama ekran örneği ... 15

3.4 Uygulama ekranı ... 18

3.5 Alan 1 ... 18

3.6 Gelişmiş arama ekranı ... 19

3.7 Alan 2... 20

3.8 Normal görünüm modu örneği ... 20

3.9 Uydu görünüm modu örneği ... 21

3.10 Karma görünüm modu örneği ... 21

3.11 Arazi görünüm modu örneği ... 22

(13)

ŞEKİLLER DİZİNİ (devam)

Şekil Sayfa

4.1 Örnek uygulama ekranı... 23

4.2 İstek örneği ... 24

4.3 Cevap örneği ... 24

4.4 Json örneği ... 25

4.5 Örnek gelişmiş arama ekranı ... 26

4.6 Örnek Tweet ... 27

4.7 Google Map konum doğrulaması ... 27

(14)
(15)

1. GİRİŞ

Sanayi toplumundan bilgi toplumuna doğru hızlı bir geçiş sürecinin yaşandığı günümüzde, bilgi her çağda farklı kanallar üzerinden paylaşılmış ve dağıtılmıştır. Basitliği ve yaygın kullanımı sayesinde internet günümüzde en yaygın kanal olmuştur. Bu bağlamda günümüzde hayatımızın bir parçası haline gelen web dünyasında iletişimi, paylaşımı ve işbirliğini kolaylaştırmak amacıyla hazırlanan yazılımların hizmet vermesi Web servisi kavramını yaygınlaştırmıştır.

İlk başlarda yerel ağlardaki belge paylaşımı tabanlı bilgi alışverişi yerini zamanla web sitelerine ve web uygulamalarına bırakmıştır. Artan web siteleri ve uygulamaları, iş yapış biçimlerindeki değişikliklerle, işletmelerin iş süreçlerini web üzerinden yaptırma gereksinimini doğurmuştur (Çelik, 2008). Şekil 1.1’deki gibi birçok farklı stil kurumsal uygulamaları entegre etmek için kullanılmaktadır.

(Pautasso et al., 2008 )

Şekil 1.1 Uygulama entegrasyon stilleri (Pautasso et al., 2008)

(16)

2

Dağıtık uygulama geliştirme, ilk olarak RPC’lerle başlamıştır. Daha sonra DCE (Distributed Computing Environment) ile ilk defa RPC’ler Standart hale getirilmiştir. DCE’den sonra CORBA (Common Object Request Broker Architecture) geliştirilmiş ve dağıtık süreç teknolojisini standartlaştırmıştır. Bir topluluk tarafından geliştirilen CORBA’dan sonra, Microsoft’un DCOM uzak nesne protokolü ortaya çıkmıştır. Bu sıralarda en başarılı dağıtık mimariler web ve e-mail olarak gösterilebilir. CORBA ve DCOM (Distributed Component Object Model)’den sonra çok popüler bir dil olan Java, RMI protokolü ile dağıtık sistemlerde büyük bir başarı yakalamıştır (Kahraman, 2003).

Restful web servis yapısı genellikle web servisleriyle birlikte kullanılır.

SOAP, RPC benzeri kullanılan sistemlere nazaran bir dizi protokol yerine var olan HTTP komutları kullanarak XML, json benzeri iletişimi hedefler. Bu Rest mimari stilini kullanan sisteme esneklik ve hafiflik sağlar.

Hazırlanan proje, Rest mimarisi ve Restful web servisleri üzerine bir incelemeyi ve kullanımını örnekleyen bir durum çalışmasını içermektedir.

Raporun ikinci bölümünde Web Servis ve Restful Web Servis kavramları anlatılmıştır. Ayrıca Restful Web Servis ile ilgili durum çalışmasında kullanılan Twitter ve Google Map uygulamaları hakkında bilgi verilmiştir. Üçüncü bölümde Twitter Rest Api ve Google Map Api incelenmiş olup iki servisin entegrasyonu ile oluşturulmuş Twitter Map Servisi’nin arayüzü açıklanmıştır. Dördüncü bölümde ise projenin örnek bir senaryo üzerinden anlatımı yapılmıştır.

(17)

2. ALTYAPI

Bu bölümde proje konusu ile ilgili Web Servis Teknolojileri ve Restful Web servislerine değinilecektir. Mevcut Rest mimarisi altyapısına sahip Twitter ve Google Map uygulamaları tanıtılacaktır.

2.1 Web Servisi ve Teknolojileri

Api (Application Programming Interface) , adından anlaşılacağı üzere bir uygulamada tanımlanmış fonksiyonların başka uygulamalarda kullanılabilmesi için oluşturulmuş arayüzlerdir.

Web servisleri farklı sistemleri entegre etmek için ve HTTP üzerinden yeniden kullanılabilir fonksiyonları ortaya koymak için bir yol sağlar. İnternet Komitesi W3C (World Wide Web Consortium) tarafından yapılan resmi tanımıyla Web Servisleri, ağ üzerinden birlikte çalışabilen makineden makineye etkileşimi desteklemek için tasarlanmış bir yazılım sistemidir. (Booth et al., 2004) Platform herhangi bir donanım, işletim sistemi (Linux, Windows, z / OS, Android, iOS gibi) yazılım çerçevesi ve Java,. NET, Ruby gibi programlama dili kombinasyonu olabilir (Daigneau and Robinson, 2012). Web servisleri, Genişletilebilir Etiketleme Dili (XML: eXtensible Markup Language) tabanlı mesajlaşmayı esas aldığı için platformların uyumlu olması gerekmez. Kısaca Web Servisleri, İnternet üzerinden kullanılabilen platformdan bağımsız API’lerdir.

2.1.1 Web Servis Modeli

Web servisleri mimarisi modeli üç ana birimin, servis sağlayıcı, servis kayıt birimi ve servis istemcisi rolleri arasındaki etkileşimler üzerine kuruludur.

Web servisleri mimarisi birimleri Şekil 2.1’de görülmektedir. Etkileşimler yayınla, bul ve bağlan işlemlerini içerir (Çelik, 2008).

(18)

4

Bir web servisi istemcisinin bir servis sağlayıcıdan bir servisi çağırma aşamasındaki temel adımlar Şekil 2.2’de görüldüğü gibi:

1. Web servisi istemcisi (SOAP Client) servis kayıt biriminden (UDDI) web servisini bulur.

2. İstemci bir SOAP mesajı hazırlar. SOAP mesajı bir XML belgesidir.

Şekil 2.2 Web Servis çağırma aşaması (Kreger, 2001; Akyokuş, 2001) Şekil 2.1 Web Servis mimari modeli (Çelik, 2008)

(19)

3. İstemci SOAP mesajını web sunucu veya uygulama sunucusunda çalışan SOAP istek dinleyicisine gönderir. İstek dinleyici gelen isteklere cevap veren sunucu programdır.

4. SOAP sunucu gelen SOAP mesajını inceler ve gerekli parametreleri göndererek istenen nesnenin istenen yöntemini çağırır.

5. Çağırılan nesnedeki yöntem çalışır ve sonuçları SOAP sunucuya gönderir. SOAP sunucusu gelen sonucu SOAP mesajı formatında biçimlendirerek istemciye gönderir.

6. İstemci gelen SOAP mesajının içindeki bilgileri alarak istekte bulunan programa gönderir. Servis istemcisi (“Service Requester”) servisleri çağırır, servis sağlayıcısı (“Service Provider”) ise istemcinin isteklerini cevaplamaktadır. Servis kayıtçısında (“Service Registry”) servis sağlayıcı tarafından yayınlanan servis tanımları ilan edilmekte ve yayınlanmaktadır. Servis sağlayıcı servis kayıtçısında servisleri tarayarak bu servisler hakkında bilgiler elde eder. (Web Servis Nedir Link 1, 2012).

2.1.2 Web Servis Teknolojileri

Web servis mimarisi bağlantı, iletişim ve tanımlamalar açısından bazı prensip ve standartları barındırmaktadır. Bu standartlar Web Servis Teknolojilerini oluşturmaktadır ve takip eden altbölümlerde açıklanmaktadır.

2.1.2.1 WSDL (Web Services Description Language)

Bir uygulamanın bir web servisini kullanması için web servisinin nasıl çağırılacağının, ara yüzünün, hangi protokollerin ve kodlama standartlarının belirtilmesi gerekir (Akyokuş, 2000). WSDL, XML tabanlı web servisleri tanımlamak ve yerini belirtmek için tanımlanmış dildir. WSDL, W3C standardıdır. Bir web servisi tanım belgesi aşağıdaki temel elemanları içerir (Işıklı, 2009) :

 Types: mesajlarda kullanılacak veri tiplerini belirtir.

(20)

6

 Message: İletişimde kullanılacak mesajları tanımlar.

 PortType: Web servisinin içerdiği işlemleri (methods) ve ilgili mesajları tanımlar.

 Binding: İşlem ve mesajlarda kullanılacak veri formatlarını tanımlar.

 Port: Binding ve web adresinden oluşan servis noktasını tanımlar.

Web adresi servisin çalıştırılacağı URL'dir.

 Service: Kullanılan port'lar kümesidir.

2.1.2.2 UDDI (Universal Description, Discovery and Integration)

Evrensel Açıklama, Bulma ve Bütünleştirme (UDDI), OASIS (Organization for the Advancement of Structured Information Standards) tarafından geliştirilmiş, web hizmetleri hakkında bilgi yayınlamak ve bulmak için kullanılan bir endüstri belirtimidir (Çelik, 2008). UDDI Kurum Kayıt Servisi (UDDI Business Registry) kurum ve Web servisleri bilgilerini saklayan sunuculardır. Bu sunucular servis sağlayıcılarından gelen bilgilerini kendi veri tabanlarına kayıt ederek diğer kurumların erişimine açmaktadır. Şu anda aktif olarak çalışan kurum kayıt sunucularına uddi.microsoft.com ve uddi.ibm.com örnek olarak verilebilir. UDDI sunucuları kurum ve servis kayıt, güncelleme ve tarama işlemlerini Web Servisleri (SOAP mesajları) ile gerçekleştirmektedir (Sünter, 2009).

2.1.2.3 SOAP (Simple Object Access Protocol)

Uzak işlev Çağırma (RPC: Remote Procedure Call) modelini kullanan, istemci/sunucu mantığına dayalı bir protokoldür. SOAP, W3C standardıdır.

(21)

Şekil 2.3’de verildiği gibi SOAP, servisler arasında yapılandırılmış bilgi alışverişini sağlayan XML-tabanlı bir iskelet sağlar. Bu bilgi SOAP Envelope (Zarf) içinde, Header (Başlık) ve Body (Gövde) şeklinde biçimlidir ve teorik olarak birçok iletişim protokolü üzerinden taşınabilir.

HTTP-bağı resmi olarak tanımlanmıştır ve bugün kullanımdadır. SOAP, RPC stilinde etkileşim sağlar ve uzak fonksiyon çağrıları ve doküman stili iletişim gibi ve mesaj içeriği sadece WSDL’deki XML şema tanımına göre hazırlanır.

Çağrı sonuçları isteğe bağlı olarak cevap mesajı ile birlikte döndürülür veya hata mesajı döndürülebilir. Aslında geleneksel programlama dillerindekine benzerdir (Türker, 2001).

Protokol dört parçadan oluşmaktadır:

 Mesaj içeriğini ve nasıl işleneceğini açıklayan bir zarf.

 Uygulamalar tarafından tanımlanabilen veri türleri için kodlama kuralları.

 Uzaktaki prosedürlerin tepkilerini temsil edebilmek için bir konvansiyon.

 Mesaj değiş tokuşu için bir bağlanma konvansiyonu.

Resim 2.3 SOAP iletişim şeması (Akyokuş, 2001)

(22)

8

2.2 Restful Web Servisleri

Bu bölümde Rest mimarisi ve bu mimariden ortaya çıkan Restful web servisleri açıklanacaktır.

2.2.1 Rest mimarisi

Rest terimi Roy Fielding’in 2000 yılında yayınlanan ve Temsili Durum Transferi anlamına gelen doktora tezinden ortaya çıkmıştır. Rest tek başına mimari değildir, bir dizi kıstaslar ile sistem tasarımına uygulanan bir yazılım mimari tarzıdır (Henry, 2011). Temelde, HTTP protokolü ile çalışan, dağıtık hypermedia sistemleri için kullanılan bir yazılım mimarisi biçimidir.

REST, kısıtlama adıyla bir grup tasarım ilkeleri kullanmaktadır. Bu kısıtlamalardan mimari model türetilmiştir. Fielding doktora çalışmasında REST’in bir grup tasarım kısıtlamalarından oluştuğuna değinmiştir (Sandoval, 2009). Fielding 6 adet kısıtlama belirlemiştir (Fielding, 2000):

 Client-Server, (Sunucu-istemci) istemci ve sunucunun birbirinden ayrılması olarak düşünülebilir. İstemcinin veri kaynağı hakkında hiç bir şey bilmemesi ve sunucunun doğru istekler geldiği sürece yanıt vermesidir. Amaç, platformdan bağımsız çalışmayı ve kapsamı arttırmaktır.

 Stateless, (Durum bilgisi) sunucuda istemci ile ilgili bir bilgi ya da session tutulmaz. İstemci tarafından yapılan her istek sunucu için gerekli bilgiyi taşır. Böylece her türlü durum istemci tarafında saklanmış olur. Sunucu hiçbir durumu saklamak zorunda kalmaz.

 Cache, (Önbellekleme) önbellek ağ performansını artırır. Veri, sunucu tarafından “cacheable” olarak işaretlenirse istemci bu veriyi bellekleyebilir. Bu durum ağ performansını artırır ve kullanıcıya daha hızlı cevap verilmesini sağlar.

(23)

 Uniform Interface, (Tek biçimlilik) sunucu ve istemci için ortak olan bu kısıtlama diğer 5 kısıtlamaya göre daha önemli sayılmaktadır. Tekbiçimli ara yüz, iletişim yöntemini basitleştirmektedir. Ayrıca ortak bir ara yüz olması sayesinde her parçanın birbirinden bağımsız bir şekilde evrimleşmesine olanak sağlamaktadır.

 Layered System (Katmanlı Sistem), istemci her durumda direkt olarak son sunucuya bağlanmayabilir, arada başka sunucular bulunabilir. Sistemde her katman tek bir katmanı bilmektedir.

Arada bulunan sunucular yük dağılımı yaparak kapsamı arttırabilmektedir ve istemcileri belirli güvenlik kurallarına zorlayabilmektedir. Bu durumun çok kullanımı istemci ve sunucu arasında gecikmelere yol açmaktadır.

 Code-On-Demand, bu kısıt opsiyoneldir. Sunucu belli durumlarda istemci tarafına çalıştırılabilir scriptler ve uygulamalar gönderebilir.

2.2.2 Restful web servisi

REST mimarisini kullanan servislere genel olarak Restful web servis denir. Restful yapısı genellikle web servisleri ile kullanılır. Web servisleri, stateless (çalışma esnasında herhangi bir durum barındırmayan) sunucu uygulamalarıdır. Web servislerinin stateless yapısı Restful bir sistemi mümkün kılar (Maboçoğlu, 2010). Rest mimarisi oluşturulmuş ve Restful Web Servislerini kullanan bir sistemde, kullanılan dilden bağımsız olarak, bilgi alışverişi XML ya da JSON formatında olur. XML (Extensible Markup Language) hem insanlar hem bilgi işlem sistemleri tarafından kolayca okunabilecek dokümanlar oluşturmaya yarayan, W3C (World Wide Web Consortium) tarafından tanımlanmış bir standarttır. Bu özelliği ile veri saklamanın yanında farklı sistemler arasında veri alışverişi yapmaya yarayan bir ara format görevi de görür (Wikipedia Link 2, 2013). JSON (JavaScript Object Notation) hafif bir veri değişim formatıdır.

İnsanlar tarafından okunması ve yazması kolaydır. Makineler içinde ayrıştırmak

(24)

10

ve oluşturmak kolaydır. JavaScript Programlama Dili Standart ECMA-262 sürümünün alt kümesi üzerine kurulmuştur. JSON, tamamen programlama dillerinden bağımsız ancak C++, C#, Java, JavaScript, Perl, Python, C ve C türevi yazılmış dillere yazılış bakımından çok benzeyen bir veri tanımlama formatıdır.

Bu özellikler JSON ‘u ideal bir veri değişim dili yapmaktadır ( Introducing JSON Link 1, 2002).

Restful yapıyı destekleyen sistem için kavramlar;

 Resource, kaynak bir sunucu üzerinde adreslenebilir herhangi bir şey olabilir. Burada kaynak istemci sunucu arasında kullanılmaktadır.

 Representation, kaynağın hangi yapıda sunulacağını belirtir.

Kaynak kaydedildiği ortamdaki orijinal halinden farklı şekilde istemciye ya da istemciden sunucuya aktarılabilir.

 URI, tek düze kaynak tanımlayıcı. Kaynağın adreslenmesi için kullanılır.

Sunucu üzerinde REST yapısının desteklenmesi için web sunucuları üzerinde asıl uygulama kodu çalıştırılmadan önce yorumlayıcı görevi gören bir REST çerçevenin olması gerekir. Bu çerçevenin görevi gelen URI bilgisinden istenilen kaynağı algılayıp asıl uygulamaya aktarmaktır.

Kaynaklar üzeri işlemler aşağıdaki gibidir;

 GET, kaynağı alır.

 POST, kaynağı oluşturur.

 PUT, kaynağı günceller.

 DELETE, kaynağı siler.

(25)

Şekil 2.4 Restful Web Servis örneği (Pautasso et al., 2008)

Bir rest mimarisinde kaynaklara ulaşmak için rest sunucu, kaynaklara ulaşan rest istemci ve değişen rest kaynaklar vardır (Şekil 2.4).

2.3 Twitter

Twitter, kullanıcılarına “tweet” olarak bilinen durumlarını bildirme ya da başka kullanıcıların durumlarını izlemeyi olanak sunan ücretsiz sosyal ağ ve mikroblog hizmetidir. Tweetler kullanıcının profilinde ve takipçi (follower) denilen kullanıcının sayfasını takip etmek isteyenlerin profillerinde görünen 140 karaktere kadar yazma olanağı veren metne dayalı postalardır. Twitter kullanıcılarına internet aracılığı ile konuşma olanağı sağlayan bir platformdur.

Twitter bireylerle diğer bireyleri buluşturur. Twitter markalarla kullanıcıları buluşturan bir ortamdır. Kullanıcılar markalara ulaşabileceği gibi, markalar da kullanıcılara ulaşabilir (Beio, 2009). Bir Tweet yalnızca metinlerden oluşmaz.

URL, medya, etiket (hashtag) içerebilir. Tweet’te yayınlanan her içerik hakkında bilgi verebilir (Twitter Platforms Entities Link 1, 2012). Hashtag, etiket anlamındadır. Etiketlemek istenilen kelimenin önüne # işareti eklenerek oluşturulur. Bu etiketlerin oluşturulma amacı çoğunlukla topluluk olarak bir

(26)

12

konuya dikkat çekmek ya da ortak konuya değinen insanları bir başlık altında toplamak amaçlanmıştır (Arslan, 2012).

2.4 Google Map

Google Map, Google tarafından sağlanan, Google Transit, Google Map Website, Google Ride Finder gibi harita tabanlı servisleri içeren ve üçüncü-parti web sitelerine gömülü harita hizmeti sunan Google Map Api’sine sahip web harita hizmet teknolojisidir (Wikipedia Link 1, 2013). Google Maps, 2005 yılında kullanıma sunulduğundan bu yana bilgisayar donanımı ve internet teknolojisinde yapılan iyileştirmelerle birlikte çevrimiçi haritaları basit, hızlı ve akıcı bir şekilde dünyanın hemen her yerini uydu, harita görünümüyle inceleme imkânı sunar.

Haritalama sistemlerinde iki türlü harita karşımıza çıkar. Bunlar, statik ve dinamiktir. Statik haritaların arama vb. fonksiyonları ve yükseklik, harita görünüm modu vb. kontrolleri olan türleri “statik interaktif haritalar” olarak adlandırılmaktadır. Kullanıcı ile etkileşime girmeyen statik haritalar ise “sadece görülebilen” haritalar olarak adlandırılmaktadır. Dinamik haritalar ise eldeki verilere dayalı olarak üretilen haritalardır. Örneğin, o anki hava durumu bilgisi, trafik bilgisi veya oy sayımı devam ederken eldeki verilere göre oluşturulan seçim sonuçları haritası dinamik harita uygulamaları arasındadır. Google Map gerek masaüstü gerekse mobil cihazlar için kullanılabilen statik haritaları destekler (Şimşek, 2010).

(27)

3 SİSTEM MİMARİSİ

Projede, Rest mimarisine uygun olarak Restful web servisini kullanan Twitter ile Google Map arasında bir uygulama arayüzü geliştirilerek Twitter Map Servisi isimli bir uygulama oluşturulmuştur. Twitter Map Servisi ile Twitter’da aranan kelimelerin geçtiği tweetlerde, konum bilgisi var ise bu bilgilerle Google Map üzerinde gösterimi gerçekleştirilmiştir (Şekil 3.1).

Şekil 3.1 Sistem mimarisi

3.1 Twitter Rest Api

Twitter Rest Api twitter işlevleri için uygulama geliştiricileri için basit bir ara yüz sağlar. Bu ara yüz ile twitter kaynaklarına erişim sorguları için gerekli dokümantasyon sunulmaktadır. Twitter’ın ekosisteminde kaynak kullanımı için belirlemiş olduğu bazı limitler vardır. Twitter’dan veri alabilmek için GET isteği gerekir. Bir veri göndermek, güncellemek veya silmek için, POST istekleri gönderilir. HTTP metotlarında olduğu gibi doğru parametreler girilmeyen sorgulara cevaplar HTTP durum kodlarında olduğu gibi döner. Bazı api yöntemleri isteğe bağlı olarak gerekli parametreleri alır. Parametrelerle isteklerini yaparken akılda tutulması gereken iki şeyden birisi parametre değerleri UTF-8

(28)

14

dönüştürülmesi gerekir ve URL kodlanmış olmalıdır. Bir diğeri ise parametrelerin 1 ile başlamasıdır. Rest Api veri erişimi veya yayınlamak için kullanıcı kimlik doğrulaması gerektiren bir dizi yöntem vardır. Bu yöntem OAuth denilen bir desen ile verilir. OAuth kullanıcıların parolalarını vermeden kendi verilerine erişebileceği uygulama kontrolü sağlayan mekanizmadır (Twitter Development Link 1, 2013) .

Twitter Api’nin iki tane özel olarak kullandığı parametre vardır:

 callback, yalnızca Json formatındaki isteklere yanıtlarda kullanılır.

 suppress_response_codes, bu parametre bulunuyor ise bütün yanıtlar 200 OK durum koduyla döner.

3.1.1 Twitter search api

Twitter Search Api, REST API v1.1 ‘in bir parçasıdır. Bu Api gerçek zamanlı Tweetleri indekslemek için sorgular sağlar. Çok kısa bir süre önce kimlik doğrulama protokollerini kullanmayan Search Api’si OAuth ile kullanıcılara kısıtlamalar ve limitler getirmiştir. OAuth işleyişiyle Şekil 3.2’de resmedilmiştir.

Şekil 3.2 OAuth işleyişi (Application-only authentication Link 1,2013)

(29)

Twitter Search Api kullanıcının belirlediği kriterlerde tweetler ile günlük ve haftalık trendleri bulmak için tasarlanmıştır. Bu kriterler anahtar kelimeleri içeren tweet dizilerini veya belirli bir kullanıcının tweetlerini bulmayı içerebilir.

Yalnızca JSON formatını destekler. Search Api’nin çalışma mantığı belirtilen sorguyla eşleşen ilgili tweet'leri döndürmektir (Get Search Link 1, 2013).

Search Api kullanırken göz önünde bulundurulması gereken şeylerden birkaç tanesi aşağıda sıralanmıştır (Using Search Api Link 1, 2013):

Limitler, sorgusu yapılan tweet indexleri en fazla altı günle sınırlıdır. Sorgular çok karmaşık ise “{"error":"Sorry, your query is too complex. Please reduce complexity and try again."}” mesajı döner. Sorguların uzunluğu operatörler de dâhil olmak üzere 1000 karakterler ile sınırlıdır.Tek istekte en fazla 100 adet tweet listeler.

 Son donanımlar, REST API v1.1’in faaliyete geçmesiyle Search Api yöntemleri diğer Rest Api yöntemleriyle aynı biçimde tweet döndürür.

 Sorgu sayılarındaki limitler, uygulamada ancak kimlik doğrulama ile 15 dakika içinde 450 istek yapılabilir.

 Doğru istekler, tüm parametreleri doğru URL kodlanmış olmalı.

URL kodlama, bir kaynağa referans eden karakter dizesidir.(

Percent-encoding URL encoding Link 1, 2012)

Şekil 3.3’de Search Api sorgularıyla arama yapılabilen bir örnek verilmiştir.

Şekil 3.3 Twitter arama ekran örneği

(30)

16

3.2 Google Map Api

Google Map Api, verilerin (resim, metin, video vb.) coğrafi koordinatlarla ilişkilendirilerek web üzerinden yayınlanmasına olanak sağlamaktadır. Google haritaları istemci tarafında Javascript dili ile kullanılabilen, uygulama programlama ara yüzü ile özelleştirilebilir olması ve platform bağımsız destek sunmasıyla bilgisayar dünyasında oldukça popülerdir.

İstemci-sunucu mimarisine dayalı harita uygulamalarında, web sunucusu istemciden gelen harita görüntüleme isteğini haritaların tutulduğu web sunucusuna iletir. Bu isteğin cevabı harita sunucusundan web sunucusuna iletilir. Web sunucusu, isteğin cevabını istemci tarafına gönderir. Burada web sunucusu harita hizmeti veren web sayfasının tutulduğu bilgisayardır.

Google Map uygulamaları istemci tarafında Javascript ve Google Map Api kullanılarak geliştirilir. Google Map Api’de bulunan fonksiyonlar kullanılarak oluşturulan haritalar, haritaları tutan web sunucudan istenir. Haritalar, Google haritalarını tutan web sunucusundan, harita isteğinde bulunan web sunucusuna iletilir ve web sunucu da haritaları istemciye gönderir (Schütze, 2007; Şimşek, 2010).

3.3 Twitter Map Servisi

Bu projede, Restful Web Servis altyapısını kullanan Twitter ile haritalama sistemi için altyapısında Javascript Api’yi ve Google Map Api’yi kullanan Google Map arasında bir uygulama yazılımı oluşturulmuştur. Google Map Rest Api’yi desteklememektedir. Google Maps'e üzerinden sunulan ve Rest Api’yi destekleyen başka servisler mevcuttur fakat bunlar ticari amaçlar için hizmete sunulmuş ve ücretli olduğundan projede Javascript Api kullanılmıştır.

Yazılımın hazırlanması için .Net platformuna dayalı Visual Studio 2010 ve C#.net programlama dili ile Windows Communication Foundation Framework (WCF) ve Windows Presentation Framework (WPF)kullanıldı.

Visual Studio Microsoft tarafından geliştirilen bir tümleşik geliştirme ortamıdır. Microsoft Windows, Windows Mobile, .NET Framework, .NET

(31)

Compact Framework ve Microsoft Silverlight tarafından desteklenen tüm platformlar için yönetilen kod ile birlikte yerel kod ve form uygulamaları, web siteleri, web uygulamaları, web servisleri, konsol ve grafiksel kullanıcı arayüzü uygulamaları geliştirmek için kullanılır (Wikipedia Link 3, 2013). WCF Framework, servis-yönelimli mimariyi temel alarak dağıtık uygulamalar geliştirmek için kullanılan dağıtık mimari modelleri ve teknolojileri tek çatı altında birleştiren ve içerisinde birçok hazır bileşen barındıran bir çerçevedir (MSDN Link 1, 2012). WPF, Microsoft tarafından geliştirilen ve DirectX kütüphanelerini kullanan kullanıcı arayüzü platformudur. İlk olarak 2003 yılında kod adı Avalon olarak Professional Developer Conference etkinliğinde .NET Framework 3.0 ile birlikte tanıtılmıştır.XAML ( eXtensible Application Markup Language) dili kullanılarak geliştirilir. XAML dili XML’den türetilmiş bir işaretleme dilidir (Çığşar, 2013). Grafiksel Kullanıcı Arayüzü olarak hazır bir şablon (Kelly, 2011), konum bilgisi listesi için ise TreeView kontrolü kullanılmıştır. Geliştirilen uygulamanın çalışmasının doğruluğu apigee konsol tarafından test edilmiştir ( Exploring the Twitter API Link1). Bu konsol apigee.com tarafından sağlanan ve uygulama geliştiricileri için hazırlanan api test motorudur. Twetter, Facebook, Youtube, Github gibi uygulamaların apileri test edilebilmekte ve birçoğunda çıktı olarak xml ve json tipi döndürebilmektedir.

3.3.1 Uygulama arayüzü

Projede geliştirilen uygulama yazılımının arayüzü Şekil 3.4’teki gibidir.

Arayüzü üç alandan oluşmaktadır: 1 numaralı alan basit ve detaylı arama alanıdır.

2 numaralı alanda konum bilgisi bulunan tweetlerin listelenmesi ve Google Map üzerinde gösterimi yer almaktadır. 3 numaralı alanda ise aranan kelimelerin bulunduğu tweetler listelenmektedir.

(32)

18

Şekil 3.4 Uygulama ekranı

3.3.1.1 Arama ve gelişmiş arama

Arama işleminin gerçekleştiği 1 numaralı alan Şekil 3.5’te gösterilmiştir.

Bu alanda metin kutusuna yazılan kelime ile Search butonuna basıldığında varsayılan arama gerçekleştirilir. Advanced Search’de (Gelişmiş Arama) ise detaylı arama gerçekleştirilir.

Şekil 3.5 Alan 1

(33)

Varsayılan arama için sorgulara dönen yanıt, kelimenin geçtiği yazılan en son tweetten itibaren 15 tanesidir. Gelişmiş Arama için kıstaslar Şekil 3.6’daki gibidir.

Şekil 3.6 Gelişmiş arama ekranı

 Language, listelenecek olan tweetlerin dil seçeneğidir.

 Count, listelenecek olan tweetlerin sayısını belirtir.

 Types: dönülen sonuçları nasıl getireceğini belirtir. Üç tür geri dönüş tipi vardır:

Mixed, populer ve recent tiplerinin sonuçlarını birlikte döndürür.

Recent, en sondaki sonuçları döndürür.

Popular, en popüler sonuçları döndürür.

 Since, verilen tarihten itibaren tweetleri döndürür.

 Until, verilen tarihe kadar olan tweetleri döndürür.

Since ve Until seçenekleri kullanılırken bilinmesi gereken, arama yapıldığı tarihten itibaren yalnızca bir haftalık tweetleri dönmesidir.

Arama kutucuğunun alt kısmında yer alan harita gösteriminde kullanılan haritalama seçenek butonu ve yakınlaştırma ayarı vardır. Bu bölüm Haritalama başlığı altında incelenecektir.

(34)

20

3.3.1.2 Haritalama

Sorgu sonrası dönen tweetler arasından konum bilgisi olan veri listeleri ve harita konumu görüntülenen 2 numaralı alan Şekil 3.7’de gösterilmiştir.

Şekil 3.7 Alan 2

Haritalama için dört adet görünüm modu vardır.

Normal görünüm modu (roadmap), yol haritası görünümü olarak da bilinir (Şekil 3.8).

Şekil 3.8 Normal görünüm modu örneği

(35)

Uydu görünüm modu (satellite), Şekil 3.9’da ki gibi uydu fotoğraflarından oluşan görünüm moduna verilen addır.

Şekil 3.9 Uydu görünüm modu örneği

Karma görünüm modu (hybrid), normal görünüm modu ile uydu görünüm modunun birleşiminden oluşur (Şekil 3.10).

Şekil 3.10 Karma görünüm modu örneği

(36)

22

Arazi görünüm modu (terrain) ise aşağıdaki Şekil 3.11’de görüldüğü gibidir.

Şekil 3.11 Arazi görünüm modu örneği

Yakınlaştırma ve uzaklaştırma (zoom) özelliği ile harita üzerindeki konum ayarı yapılmaktadır.

(37)

4 ÖRNEK BİR UYGULAMA SENARYOSU

Bu kısımda projenin örnek bir kullanım senaryosu üzerinden gösterimi Şekillerle açıklanarak anlatılacaktır.

Şekil 4.1 Örnek uygulama ekranı

Şekil 4.1’de genel hatlarıyla varsayılan arama uygulama ekranı verilmektedir. Kırmızı kutucuklarla belirtilmiş içerisinde konum bilgisi yer alan tweet harita üzerinde şekildeki gibi gösterilmiştir.

Aranacak kelime “kebap” ve Twitter Api’ye gönderilen sorgu,

“https://api.twitter.com/1.1/search/tweets.json?q=kebap” şeklindedir. Bu sorguya göre Twitter’a yapılan istek Şekil 4.2’deki gibi apigee konsol uygulamasından gönderilmiştir.

(38)

24

Şekil 4.2 İstek örneği

Yapılan isteğe karşı dönen cevap Şekil 4.3’deki gibidir.

Şekil 4.3 Cevap örneği

(39)

Şekil 4.4’de https://api.twitter.com/1.1/search/tweets.json?q=kebap isteğine karşı dönen cevabın json formatı gösterilmektedir.

Şekil 4.4 Json örneği

(40)

26

Şekil 4.5 Örnek Gelişmiş Arama ekranı

Detaylı arama sorgusu arama ölçütleri Şekil 4.5’teki gibidir. Twitter

Api’ye gönderilen sorgu ise

“https://api.twitter.com/1.1/search/tweets.json?q=kebap+since:2013-06-

08+until:2013-06-10&lang=tr&result_type=mixed&count=50&include_entities=1

“ şeklindedir.

(41)

Şekil 4.6 Örnek Tweet

Şekil 4.6’da sorguya göre seçim ölçütlerinden tarih aralığı ve konum bilgisi Twitter’ın sitesinden doğrulanmıştır.

Şekil 4.7 Google Map Konum Doğrulaması

Ayrıca Şekil 4.7’te görüldüğü gibi Google Map sayfasından konum doğrulaması yapılmıştır.

(42)

28

5 SONUÇ

REST’ in başarılı şekilde kullanılması veri setinin anlaşılması, anahtar kaynakların belirlenmesi, bu kaynaklar ile hangi işlemlerin yapılacağını belirlenmesi ve verinin URI ile adreslemesinden geçer. REST ’in uygulanması için herhangi bir özel araca gerek yoktur.

Standart bir tanımlamaya ihtiyaç duymaması, veri alışverişinin SOAP gibi tek bir formata bağlı kalmadan HTTP metotlarından yararlanılması uygulama geliştiricileri için kolaylık ve esneklik sağlar.

Proje kapsamında yapılan inceleme ve uygulama geliştirme aşamasında Restful web servisi ve Rest mimarisi ile ilgili görülen avantaj ve dezavantajlar aşağıda listelenmiştir. Avantajlar;

 Tüm kaynaklar ve kaynakların bağlantıları eşsiz olarak tanımlanıp URI olarak adreslediği için doğru veri erişimi sağlar.

 Her HTTP isteğinde yapılması istenilen işlemin HTTP metotlarıyla ifade edilmesi proxy ihtiyacını ortadan kaldırmakta ve platform bağımsız yapılara elverişli hale getirmektedir.

 Veri gönderilmez, bunun yerine veri linki metadata ile birlikte gönderilir. Böylece ağ trafiği daha az kullanılır ve işlem kapasitesi arttırılmış olur.

 Hızlı ve kolay uygulanabilir, senkronize duruma ihtiyaç duymaz.

Dezavantajları;

 REST kullanan sunucular ve istemciler HTTP/Web uygulamaları gibi savunmasızlardır.

 HTTP komutlarının uygun olmayan şekilde kullanılmasıyla RPC metotlarına dönüşebilir ve Restful çözümü geçerli olmaz.

 Tanımlı kütüphaneler azdır, geliştiriciye ek iş yükü oluşabilir.

Android uygulamaları ile diğer iletişim cihazları haberleşme konusunda web servisleri çok aktif bir şekilde kullanılmaktadır. Bu projenin devamında yapılacak bir çalışma kapsamında da akıllı telefon, tablet vb. teknolojilerde kullanılmak üzere android işletim sistemi ile uyumlu hale getirilebilir.

(43)

KAYNAKLAR DİZİNİ

Akyokuş S. , 2000, Bilişim Zirvesi 2000 "XML ve XML Uygulamaları" Seminer Notları

Akyokuş S. , 2001, Web Servisleri: İnternet Devriminde İkinci Aşama, http://www.godoro.com/Divisions/Ehil/Mecmua/Magazines/Articles/

txt/html/article_WebServices.html

Application-only authentication Link 1, 2013,

https://dev.twitter.com/docs/auth/application-only-auth

Arslan A., 2012, Twitterdaki Terimler Ve Anlamları, http://www.blogkafem.net/2012/07/twitterdaki-terimler-ve-

anlamlar.html#.UNzWZnf-1kc

Beio J. , 2009, Twitter 101, http://www.slideshare.net/lilmissjen/twitter-101- 1385082

Booth D. , Haas H., McCabe F., Newcomer, E., Champion, M., Ferris, C.

and Orchard,D., 2004, Web Services Architecture, http://www.w3.org/TR/ws-arch/wsa.pdf

Çelik, H., 2008, Web Servisleriyle İlgili Elektronik Ticaret Uygulaması, Yüksek Lisans Tezi, Haliç Üniversitesi Fen Bilimleri Enstitüsü Bilgisayar Mühendisliği, 58s.

Çığşar, A., 2013, WPF (Windows Presentation Foundation) Giriş, http://www.ahmetcigsar.com/yazilim/wpf/wpf-windows-

presentation-foundation-giris/

Daigneau, R. and Robinson, I., 2012, Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services, Pearson Education, United States of America.

Kelly, E., 2011, TweetSearch – The C# Twitter Search Engine, http://www.jarloo.com/

Exploring the Twitter API Link1, 2013, https://dev.twitter.com/console

Fielding R. T. , 2000, Architectural Styles and the Design of Network-based Software Architectures, PhD thesis, University of California, Irvine, 152p.

Get Search Link 1, 2013, https://dev.twitter.com/docs/api/1/get/search

(44)

30

KAYNAKLAR DİZİNİ (devam)

Henry, B., C., 2011, Appling The Rest Architectural, A Thesis, Regis University, 54p.

Introducing JSON Link 1, 2002, http://www.json.org/

Işıklı, B., 2009, Web Servis Nedir, http://burakisikli.wordpress.com/tag/uddi/

Kahraman, B. Ö., 2003, Web Servisleri ve Kayıtçılar (UDDI & RDF), http://www.csharpnedir.com/articles/read/?id=106

Kreger, H., 2001, Web Services Conceptual Architecture, IBM, http://www.cs.uoi.gr/~pitoura/courses/ds04_gr/webt.pdf

Maboçoğlu A. , 2010, Restful Web Servisleri İle Ontoloji Sorgulama, Yüksek Lisans Tezi, Tobb Ekonomi Ve Teknoloji Üniversitesi, 46s.

MSDN Link 1, 2012, What Is Windows Communication Foundation, http://msdn.microsoft.com/en-us/library/ms731082.aspx

Percent-encoding URL encoding Link 1, 2012,

http://en.wikipedia.org/wiki/Percent-encoding

Pautasso, C. , Zimmermann, O. and Leymann, F., 2008, REST vs. SOAP Making the Right Architectural Decision , SOA Symposium 2008, http://www.jopera.org/files/soa-amsterdam-restws-pautasso-talk.pdf Sandoval J. , 2009, Restful Java Web Services, Published by Packt Publishing

LTD, Birmingham, 235p.

Sünter, H., İ., 2009, Web Servisi Standartları, http://www.halilsunter.com/category/Web-Servisi-

Standartlarc4b1.aspx

Schütze, E., 2007, Current state of technology and potential of Smart Map Browsing in web browsers, Multimedia Technology Department, Thesis, Bremen Universiyt of Applied Science, Germany, 128p.

Şimşek Ö. , 2010, Google Haritaları Tabanlı Mobil-Destekli İnteraktif Web- Harita Oluşturucu Uygulaması Geliştirme, Yüksek Lisans Tezi, Anadolu Üniversitesi, 79s.

Türker, M., A., 2001, Web Servisleri, http://inet-tr.org.tr/inetconf7/bildiriler/

Twitter Platforms Entities Link 1, 2012, https://dev.twitter.com/docs/platform- objects/entities

(45)

KAYNAKLAR DİZİNİ (devam)

Twitter Development Link 1, 2013, Implementing Sign in with Twitter, https://dev.twitter.com/docs/auth/implementing-sign-twitter

Using Search Api Link 1, 2013, https://dev.twitter.com/docs/using-search Web Servis Nedir Link 1, 2012, Web Servis Teknolojileri,

http://www.msxlabs.org/forum/pc-internet-yazilim-donanim/397058- web-servis-teknolojileri.html#ixzz2VuFT3z5P

Wikipedia Link 1, 2013, Google Maps,

http://en.wikipedia.org/wiki/Google_Maps#cite_note-1 Wikipedia Link 2, 2013, XML, http://tr.wikipedia.org/wiki/XML

Wikipedia Link 3, 2013, Microsoft Visual Studio, http://en.wikipedia.org/wiki/Microsoft_Visual_Studio

(46)

32

ÖZGEÇMİŞ

Özge ÖZKAYA 1985 yılında İzmir’ de doğdu. 2003 yılında İzmir Atatürk Anadolu Lisesini bitirdi. 2010 yılında Ege Üniversitesi Fizik bölümünden mezun oldu. 2011 yılında başladığı Ege Üniversitesi Uluslararası Bilgisayar Enstitüsü’ndeki 2. Öğretim tezsiz yüksek lisans eğitimine bu proje yazıldığı tarihte devam etmektedir.

Referanslar

Benzer Belgeler

Çalışma kapsamında, ilk olarak pek çok web tabanlı uygulama geliştirme çatısı incelenmiş ve daha sonra öğretim elemanlarına yönelik bilgi yönetim

Arkadan boğulmuş düz yapı Önden boğulmuş düz yapı... Arkadan ve yandan normal

How- ever, of the ten studies, five examined the relationship between blood cells and coronary artery diseases.. So we can categorize the studies in two groups: those associated

(四)預期完成之工作項目及成果。請列述:1.預期完成之工作項目。2.對於學術研究、國家發展及

(1) oxLDL may induce radical-radical termination reactions by oxLDL-derived lipid radical interactions with free radicals (such as hydroxyl radicals) released from

Ordered probit olasılık modelinin oluĢturulmasında cinsiyet, medeni durum, çocuk sayısı, yaĢ, eğitim, gelir, Ģans oyunlarına aylık yapılan harcama tutarı,

Laparoskopik sleeve gastrektomi (LSG) son yıllarda primer bariatrik cerrahi yöntem olarak artan sıklıkla kullanılmaktadır. Literatürde, LSG’nin kısa dönem sonuçları

Ayrıca, hidrofilleştirme işleminin ananas lifli kumaşlar üzerine etkisinin değerlendirilebilmesi için direk ham kumaş üzerine optimum ozonlu ağartma şartlarında