Rest API에 대한 깨달음

REST API의 근간

과거에 다음, 한미르 같은 시절에는 WAS가 없었고 Nginx, apache 같은 Web Server 만 있었다. Web Server 는 정적인 파일을 serving 해준다. 사용자가 이미지 던져달라하면 던져주고 html 던져달라하면 던져주는 방식이다.

 

옛날에는 “im.html”을 던져달라하면 나의 개인정보가 나오는 html파일을 던져주곤 했다. 그러다 보니 그 당시 서버는 html 파일 서버였던 것이었다. 다시 말해 그 당시에는 우리가 그 html에 접근하기 위해서는 url에 “user/im.html” 를 요청하면 파일을 달라고 요청하는 것이었다. 그러면 html 웹 서버가 디렉토리에서 뒤져서 파일을 찾아서 주는 것이었다.

 

만약 그 위치에 파일이 존재하지 않으면 not found를 던져주는 것이고 url에 잘못 쳐서 “user/em.html” 을 요청하면 양식이 맞지않다고 400에러를 준다. 여기 개념에서 부터 Rest API가 나온 것이다.

 

 

REST API 설계

html파일도 정적 Resource를 호출하는 것이기 때문에 Rest API 는 어떻게 보면 Resource를 호출하는 것이다. 그러니까 우리가 Rest API 를 만들 때도 가상의 디렉토리가 있다고 생각하고 Rest API를 설계한다고 생각하면 쉽게 된다. 밑에를 예를 들면 파일 서버 안에 shops라는 폴더가 있고, 그 안에는 1번 id를 가진 애가 있고 얘는 “싸다김밥”이고, 2번 id를 가진 애가 있고 얘는 “메가커피”이다. 그러면 디렉토리 구조라고 쳤을 때 다음과 같은 구조를 가지게 된다.

 

shops
├── 1
│   ├── 싸다 김밥
└───└── 메가 커피

이런 구조에서 1번 디렉토리에 있는 정보를 들고오고 싶으면

GET + /shops/1

를 해서 들고오면 되는 것이다.

 

그리고 shops라는 디렉토리 내에 새로운 무언가를 만들려고 하면

POST + /shops

를 요청하게끔 하면 되는 것이다.

 

업데이트와 삭제도 마찬가지이다.

PUT + /shop/1

DELETE /shops/1

이런식으로 하면 된다.

 

 

REST API 행위 구분

Rest API의 특징중에 “유니폼 인터페이스”라고 있다. 유니폼이란 같은 옷을 입고 있다는 뜻이다. 이것을 제어 하는 것은 Http method(GET, POST, PUT, DELETE) 로 행위를 제어해야한다. 즉 End point는 동일한데 Http method를 가지고 행위를 다르게 한다는 뜻이다.

 

 

응용을 해보면

teams
├── 1
│   └── 법무팀
├── 2
│   └── 홍보팀
├── 3
└───└── 영업팀

이 있고

teams
└── 1
    └── memebers
           └── 홍길동

트리구조로 이렇게 "법무팀에서 일하는 홍길동 사원을 찾고싶을 때"

GET + /teams/1/members/1

요청으로 찾으면 “홍길동”이 결과로 나오는 것이다.

 

결론은 “파일” 처럼 보면 된다. 그러면 Rest API 설계가 굉장히 쉬워진다.