REST API 혹은 RestFul이란 무엇인가?

출처 및 참고:

http://egloos.zum.com/killins/v/3092502

#REST API

#REST API란 무엇인가?

#RESTful

#RESTful이란 무엇인가?

#Representational State Transfer

일단 정의를 보자.

REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었습니다. 로이 필딩은 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 합니다.

저걸 다 외우려고 하면 제정신이 아니지.

누군가 너 레스트풀 뭔지 아늬??

물어본다면...

간단히 말해서,

"URI와 HTTP 메소드를 이용해 객체화된 서비스에 접근하는것"

이라고 쿨하게 대답하면 됨.

개념잡으려고 이곳 저곳 돌아다니며 많이 살펴보았는데 머리만 아프다

걍 저정도만 알고 넘어가까..

나머진 나중에 봐도 된다. 

그래도 특징과 장단점 정도는 SSG~ 알아두자

---

REST 특징

  사실 REST는 ROA를 위해 태어났다해도 과언이 아니기 떄문에, ROA의 4가지 속성(Addressability, Connectedness, Statelessness, Homogeneous Interface)과 깊은 연관이 있다.

  - Stateless : Statelessness

  REST의 가장 큰 강점 중 하나이다. 이전, 이후에 대한 직접적인 정보가 필요없이 직관적인 오브젝트에의 접근으로 서비스를 처리한다. 세션정보를 보관할 필요가 없기 때문에, 서비스의 자유도 또한 높아지고 로드밸런싱이라든지 기타 유연한 아키텍처의 적용이 가능하다. 

쿠키/세션, 필요없다.


  - URI를 이용 : Addressability

  REST는 모든 유일한 오브젝트에 대해 유일하고 직관적인 URI을 통해 접근하도록 한다. 설명보다는 예를 하나 보는것이 간단한데, 서울대학교의 대학원생들 중 학번이 12345657인 사람의 정보를 얻어오고자 한다면 아래와 같이 표현 가능할것이다.

www.univinfo.co.kr/seouluniv/undergraduate/student/code/1234567

  사실 단순히 저런식으로 표현하는것이 중요한게 아니라, 특정 오브젝트에 접근할때 특정 URI를 통한 접근이 가능한지가 중요하다. 인터넷 메일을 확인할때, 어떤 메일은 특정 주소에서 반드시 특정 링크를 클릭해야지만 메일을 확인할 수 있고, 어떤 메일은 특정 메일을 특정 주소로 접근 가능할 수 있다. 후자가 REST 서비스이다. (당장 지메일의 수신 메일 하나를 클릭한 후 브라우저 주소창에 뜬 주소를 살펴보면 알 수 있을 것이다)


  -  HTTP 메소드를 사용 : Homogeneous Interface

  Homogeneous의 해석에 따라 의미가 갈릴수도 있는데, 동종의 인터페이스만을 사용한다고 보면 된다. 

즉, REST는 HTTP에서 제공하는 GET, PUT, POST, DELETE 4개의 메소드(여기에 HEAD나 OPTION을 추가하는 경우도 있다)를 이용해서 서비스를 제공한다. 

한편으로는 이것이 REST의 단점이 되기도 하는데, 결국 HTTP 4개 메소드가 DB의 CRUD와 같은 기능을 하기 때문에

(C:POST, R:GET, U:PUT, D:DELETE), 이러한 유형으로 분류할 수 없는 작업에 대해서는 어떻게 처리해야 할 지가 조금 모호해지기도 한다. 

(이메일을 보낸다든지...) 이런 경우 URI를 적절히 정의함으로써 가능하지만, 실제로 서비스별로 URI을 어떻게 정의할 것인가가 REST 설계에 있어 가장 어려운 부분이다.


  - Connectedness

  사실 이부분이 좀 애매하다... 연결성이란것이 서비스내 하나의 리소스가 다른 리소스들간의 관계에 의해 표현되어질 수 있다는 정도로 해석하면 될 것 같다.

장점!

REST는 통용되는 표준 아닌 표준이 있기는 하지만, 사실 위의 특징들만 잘 지켜서 간결하게 서비스에 접근 가능하다면 그게 REST이다. 

REST를 지원하는 프레임워크라든지, 언어라든지 이런 도구들이 없어도 얼마든지 구현 가능하다. 

이 얘기는 곧 기존의 자원들을 그대로 활용 가능하다는 뜻이 된다. REST 도입을 위해 무언가 굉장히 큰 노력을 기울일 필요가 없다는 것이다.
단점!  

반면 단점 역시 명확한데, 표준이 없다는게 단점이다. 각 서비스별로 아키텍처가 다르기 때문에, 이것에 따른 서비스 방안 역시 다를 수 밖에 없다. 그리고 설계나 구현 시에 머리를 써야한다. 단순 CRUD 만으로 표현 불가능한 서비스들이 많기 때문에 고민을 해보고 일을 해야 한다는 뜻이다. 생각없이 뚝딱뚝딱 만들다가는 위에서 얘기한 문제들에 봉착해서 이러지도 저러지도 못하는 수가 생긴다.