Merhaba Arkadaslar
Bu bolumde HTTP Content Negotiation konusunu inceleyecegiz.
Negotiation “müzakere, uzlaşma” gibi anlamlara gelmektedir.

SOA (Service-Oriented Architecture) yapisina uygun uygulamalar , farkli farkli istemciler ve platformlar nedeniyle son derece esnek olmalidirlar.

SOA (service-oriented architecture) applications need to be flexible enough to 
handle and integrate with a variety of clients and platforms

Farkli istemciler farkli formatlara uygun olarak calisabilirler.
Ornegin RESTful uygulamamizdan hizmet alan bir java uygulamasi data’nin XML formatinda olmasini isterken , bir Ruby uygulamasi YAML formatinda .NET uygulamasi ise JSON olarak isteyebilir.

HTTP bu gibi entegrasyon problemlerine karsi yardimci olabilecek cozumler sunmaktadir.

Conneg

Conneg , HTTP Content Negotiation kavraminin kisaltilmis halidir.
Client HTTP Accept header’inda tercih ettigi format bilgisini liste halinde gonderebilir.

Clients set an Accept request header that is a comma-delimited list of preferred formats.

Ornek olarak ;

 GET http://example.com/stuff
 Accept: application/xml, application/json

burada /stuff adresine client istekte bulunmakta ve cevap formati olarak XML ya da JSON istenmektedir.
Eger server istenen formati desteklemiyorsa bu durumda HTTP 406 Not Acceptable status code lu hata donecektir.

Preference Ordering

Tercih sirasi olarak Accept header’inda duzenleme yapabiliriz.
Daha ozellesmis/ozel olarak belirtilmis media type daha az ozellesmis olandan oncelikli olacaktir.

The implicit rule is that more specific media types 
take precedence over less specific ones

Ornek olarak ;

    
    GET http://example.com/stuff
    Accept: text/*, text/html;level=1, */*, application/xml

Dikkat edecek olursak 4 farkli media type bilgisi yer almaktadir. Her biri virgul ile ayrilmis durumdadir.
Burada spesifik bir media type belirtebildigimiz gibi wildcard(*) da kullanabiliriz.
Oncelik siralamasi su sekilde olacaktir ;

1. text/html;level=1
2. application/xml
3. text/*
4. */*

1.sirada text/html;level=1 olacak cunku en spesifik olan budur.
application/xml 2.sirada gelecektir , cunku MIME type properties yer almamaktadir , (text/html de level=1 yer almaktadir)
3.sira olarak wildcardlarda text/* daha spesifiktir. Son olarak oncelik sirasinda */* yer alacaktir.

Istemci/Client oncelik sirasini belirtirken “q” MIME type property degerini kullanabilir.
Bu deger 0.0 ile 1.0 araliginda olmaktadir. Eger herhangi bir “q” property yoksa bu durumda varsayilan olarak 1.0 degeri kabul edilmektedir.

Clients can also be more specific on their preferences by using the q MIME type property. 
This property is a numeric value between 0.0 and 1.0, with 1.0 being the most preferred.

Ornek olarak ;

GET http://example.com/stuff
Accept: text/*;q=0.9, */*;q=0.1, audio/mpeg, application/xml;q=0.5

Siralama su sekilde olacaktir;

1. audio/mpeg
2. text/*
3. application/xml
4. */*

Eger q degeri belirtilmemisse bu durumda 1.0 olarak degerlendirilir.
Bu durumda 1.oncelik auido/mpeg olacaktir.
Sonrasinda text/* icin q degeri 0.9 dur. text/* application/xml den daha az ozellesmis/spesifik olsa da q degeri daha buyuktur.
3.sirada application/xml gelecektir , q degeri 0.5
Son olarak */* gelecektir q degeri 0.1

Language Negotiation

Language/dil konusundaki “uzlasma/megotiation”  icin Accept-Language header bilgisi kullanilmaktadir.

Clients use the Accept-Language header to specify 
which human language they would like to receive

    GET http://example.com/stuff
    Accept-Language: en-us, es, fr

Accept-Language ta belirtilen 2 karakterli dil/language formati ISO-639 standardina uygun sekilde olmaktadir.
https://www.w3.org/WAI/ER/IG/ert/iso639.htm

Ulke kodu/country code da ISO-3166 standardina uygun sekilde olmaktadir.
https://www.iso.org/new-way-of-using-iso-3166.html

Accept-Language , ek olarak q parametresini destekler.

    GET http://example.com/stuff
    Accept-Language: fr;q=1.0, es;q=1.0, en=0.1

Encoding Negotiation

Message body/response konusunda da bir uzlasma/Negotiation header bilgisi yer almaktadir ; Accept-Encoding
Accept-Encoding header parametresi istemcinin desteklemis oldugu encodingleri belirtmek icin kullanilir.
En cok kullanilan algoritma GZIP tir.

 Clients use the Accept- Encoding header to specify which encodings they support. 

    GET http://example.com/stuff
    Accept-Encoding: gzip, deflate

Istemci cevabin GZIP kullanilarak compress edilmis olmasini ya da uncompressed(deflate) olarak kabul ettigini ifade etmektedir.

Benzer sekilde Accept-Encoding de q parametresini kullanmaktadir.

    GET http://example.com/stuff
    Accept-Encoding: gzip;q=1.0, compress;0.5; deflate;q=0.1

Github kaynak kodlar / source folder
injavawetrust.resteasy
injavawetrust.jersey

Yazimi burada sonlandiriyorum.
Herkese Bol Javali Gunler dilerim.