WebService의 진화(?) REST Architecture..

한때 WebService를 통해 시스템을 연동하는 프로젝트를 수행한 적이 있다.
기존 시스템이 사용하던 RPC나 CORBA방식의 연동에 비해 엄청나게 쉬운 방법으로 I/F가 가능하고 HTTP기반에 SOAP프로토콜로 시스템에 상관없이 연동이 될수 있다는 점에서 개인적으로 이 기술이구나(한번 배워놓으면 10년은 사용할 수 있겠다...ㅋ)라는 생각을 했었는데..
웬걸... .NET 프로젝트에서 전략적(?)으로 사용하던 WebService가 java기반의 프로젝트로 옮기고는 사용을 하지 않는 것이었다. 프로젝트 수행 인력들이 새로운 기술에 대해 익숙치 않아 DB-Link에서 EAI 사용으로 바로 이동하게 된 것이 원인일 꺼라고 생각했는데..(EAI는 EAI 담당자만 해당 기능에 대해 신경을 쓰면 된다.)
기업용시스템은 안정성에 대한 보장이 되야 하는 특성으로 인해 그렇다치고, 각 포털의 공개 API도 WebService가 사용된다는 소식이 없으니..(난 웹서비스를 접하면서 지금의 AppStore처럼 커다난 UDDI에 개발자들이 기능을 등록하고 자유롭게 가져다 사용하면서 웹 환경을 풍요롭게 만들어 줄꺼라고 생각했었다-_-;)
지난주에서야 웹서비스는 spec의 복잡성과 사용의 불편성으로 인해 REST(REpresantational State Transfer)라는 방식으로 진화(?) 했다는 사실을 뒤늦게 알게 되었다(바보T_T)
예전에 웹서비스로 구현할 수 있습니다라고 말하면 "아.. 우리도 웹으로 서비스하고 있어요." 라고 말하던 사람들이 틀린게 아니라는게.. 참....

이제 REST를 알아보자~


참고 사이트
http://blog.eloitcube.co.kr/41