Menu

3 Eylül 2009 Perşembe

GOALS - NONGOALS(Avantaj-dezavantaj)

Bir onceki makalemizde RESTFul web servislerin ne oldugunda nasil calisdigindan bahsetmisdik, bu makalemizde ise goals-nongoals( avantaj- dezavantaj)`larinda bahsedecegiz.

GOALS(Avantaj)
-POJO-Based;
POJO tabanli olacak, cok fazla complex arayuzler(interface) kullanmaya ihtiyacimiz olmayacak

-HTTPCentric;
Http merkezli olacak, yani baska protocolleri desteklemeyecem cunku basit olmali.

-Format indenpendece;
Formattan bagimsiz olam, yani biz bugun web arayuzleri nasil MIME tipini gosterebliyorsak ayni sekilde kullanabilmek.

-Container indenpendice;
Contanierden bagimsiz olma, (Application server)

-inclusion in Java EE;
JavaEE specifikasyonunu kullanimi


NONGOALS(Dezavantaj)
-support for java version prior to J2Se 5.0;
Yani j2se 5.0`dan onceki surumler desteklenmez.

-Description, registration and discovery;
WSDL, UDDI, vb. kullanilmamasi(tabii bu dezavantajmi :) )

-Client API;
Istemci APIs spesifikasyonu disinda

-data model/format classes;
Yani model bicimden uzak duracagim, Cunku onlari implemente ederken HTTP stock buyuyor.


Terminology
Resource classes;
WebServisi adi altindan uzaklasiyorum, bu yuzden neyi sunuyorsam onun adina resources diyecem.

Root Class;
Root sinifinin uzerinde path olmali, ve bu URL`de olacak.

Request method designator;
Http biz method annotationlarindan hangisini dinleyecegi


Provider
Yani biz MIME tiplerinden bagimsiz bir veri sundugumuz icin, yani MIME tiplerine bagimli olmasin, muhakkak xml olmasin, muhakkak json olamsin vs.
Peki bizim istedigimizi bu MIME tiplerinden hic biri saglamiyor ise, bu durumda provider annaotationu ile providerleri tarife etmemiz gerekiyor. Yani ben sana bir nesne gonderiyorum, bunun icin detaylari kullanmak icin bu provider class`ini kullanmaliyiz.
NOT: Ilerki makalelerde ayrinliti bir sekilde gorecegiz, ve orneklerle anlatmaya calisacagiz
Mesala bir uygulamamiz var, ben buna bir @Path("sirket") annotationu vermisim,
-@Path annotationlarini hem metodlarda, hemde class seviyesinde rahatlikla kullanabiliriz.
Peki hem class`da hem metodda kullanirsak ne olacak? ozmanda, su olacak, once class uzerinde path daha sonra metod uzerindeki path, yani

http://localhost:8080/webapp/resources/sirket/calisan
burada,
webapp - Bizim web.xml icindeki uygulamamizin adi,
resources - Servlet kaynagi
sirket - Bizim classimizin adi
calisan - Sirket class`imizin icindeki metod adi

@Path("sirket")
public class Sirket{

@Path("calisan")
public ..... calisan(){
...
...
}
.....
.....
}

@Path annotaionunlarini metodlarda kullaniyorsam, ozellikle hagi HTTP metoda karsilik geldigini belirtmem gerekiyor. Yani(GET`mi, POST`mu vs.). Biz belirtmezsek, default olarak @GET calisir
Mesala bir metodun
@GET
@Path("message")
public Srting getMessage(String mess){
-- - - - - -- - - -- -
- -- - -- - - - -
}
bu nasil calisacak
Burada en sonda belirtigimiz merhaba dunya, metodumuzun parametre degeri yani mess` deger gondermis oluyoruz. Bunlari ilerki makalelerde cok daha ayrintili bir sekilde gorecegiz
NOT: Bir method birden fazla requesti kabul ediyor olabilir. Yani ayni zamanda hem GET`i hem POST`u kabul ediyor olabilir.

Hiç yorum yok:

Yorum Gönder