0218.txt

예, 포프입니다.
오늘은 오랜만에, 웹 얘기를 해보죠.
반드시 웹 쪽은 아닌데, Restful API라고 하나?
예를 들어서, 트위터나 페이스북 API 쓰신분들은 알거에요.
심지어 트위터를 웹에서 쓰시는 분들은 알거고,
이제, HTTP에서, 웹쪽에서 뭔가를 가져올 때
도메인이 있고, 만약에 친구를 갖고 싶으면 friends 하고 슬래쉬(/) 하고
하면 전체 friends가 오고
아니면 더 간단히, 이렇게 하자.
트위터하고 내 이름 하고 슬래쉬
 트위츠 하면(www.twitter.com/myname/tweets)
제 트윗이 다 나와요, 그리고 거기다 슬래쉬 하나를 더 긋고 어떤 아이디를 넣으면
그 아이디 트윗만 나오고
API에 있는 각 토큰이라고 할까요?
토큰이라고 해야하나?
그게 점점 필터링의 기능을 하는것처럼 만드는
그런 API 규약이 RESTful API가 있어요
제일 중요한거는
state가 없는 규약이라는게 중요한거에요
내가 API 호출하는, 그,
호출과 헤더만으로 내가 원하는 데이터는 와야한다
내가 이전에 여기에 왔었다는걸 쿠키에 기억해서
그 쿠키에 의존해서 다시 보내는 이런게 아니라
그 순수하게 API 하나만으로도
내가 원하는 데이터를 가질 수 있고
이 서버라던가 뭐던가는
내가 그 전에 뭔 일을 했는지에 대한
상태를 저장하지 말아야 한다는 그런 개념으로 시작한게 RESTful API
상당히 많은 웹API들이 따라가고 있구요
근데 RESTful API를
스펙을 제대로 읽어보면은
이거를 완벽하게 하고 있는 사람은
거의 없다고 보면 맞아요
여러가지 단계가 있어요.
최소한 이 정도면은 레벨1, 레벨2, 레벨3 이런식으로
얘기를 하는데
결과적으로 중요한거는
어떤 스펙이 나와도 이걸 완벽하게 지킬 수 있다는게 아니라
이거를 그냥..
내가 정해놓은 원칙에서
회사가 정해놓은 원칙에서,  좀  consist 하게
그러니까 좀 일관적이게
규율을 따라 갈 수 있으면
어떤 API를 쓰던간에 이걸 이제 예상하기가 쉽다는거죠
예를 들어서, 뭐, 제가 아까 말했듯이
tweets하고 id 넣으면 새로운 트위터가 나온다면은
friends 넣고 id를 넣으면 그 friend가 딱 나온다던가
이런식의 개념으로 좀 규약화된 API
이런 개념이 강해요
이게 나온 이유가 분명히 예전에 웹쪽에서
제가 정확히 이름은 기억이 안나는데
"쏩?"쪽이던가
그 쪽에서
모든 함수를 불러오는 API 라던가
심지어 URL을 쓰더라도
get 어쩌구, put 어쩌구, update 어쩌구
이런식으로 URL를 많이 짰던거 같아요
HTTP쪽은 기본적으로 내가
리퀘스트(request)를 보낼 때
GET인지 POST인지 그게 일단 가장 기본적인 거고
버전이 넘어가면 PUT 이런것도 있고,
Update도 있던가?
아니야 PUT이 업데이트고
GET말고 뭔가 몇개가 Delete가 있구나, Delete도 있고
그런, 또, HTTP 1.1은 그런
규약이 아예 있고
그래서 그거와 상관없이 그냥
데이터로 구분하자에요
예를 들어서, 만약에 내가 friends 하고 id를 넣었는데
이거 URL을 보내면서 내가 HTTP GET을 넣었다면
그걸 가져오는거고,
HTTP PUT을 넣었다면, PUT이 되는거고 이런식으로
좋은 아이디어이긴 해요, 굉장히 규약화 되있고, 깔끔하고
그리고 어찌보면은 URL, 이제
인터넷 URL을 보면 보통 거기엔 명사가 들어가지
거기에 동사가 들어가는 일은 좀.. 어색하잖아요
내가 물건을 사러가도,  물건 리스트를 볼 때
show me the list 이런식으로 쓰지 않잖아요
그냥 product/baby 이런식으로
베이비를 사는 건 아니고.. 베이비 제품을 사는거죠(웃음)
그래서, 좋은 거긴 한데
되게 재밌는게 그거에요
버저닝(versioning)
그러니까 API가 버전이 있잖아요
제가 첫번째 버전에서는 이런걸 했는데,
두번째 버전에서는 좀.. 바뀌었어
그러면.. 이 버전을 어떻게 해야되냐..?
제가 이제, 이거는
트로이 헌트(Troy Hunt) 라는 아저씨가 쓴 블로그 글에서 보고
제 마음을.. 최근에 결정지은건데
그 분이 하시기를
API 버전을 넣는 방법에는 세 가지 틀린 방법이 있다고 얘기해요
옳은 방법은 전혀 없고, 세 가지 틀린 방법이 있다고.
첫번째 방법은
API 앞에 버전번호를 넣는거에요
그래서 어떤 API를 보면.. 페이스북 쪽이 그랬나?
아니면.. 트위터가 그랬..? 아니야, 구글인거같다
구글이 그랬던거 같은데
API 도메인 나오고 거기다가 v1그리고 slash 넣고
RESTful URI
그리고 두번째 버전 나올떄는 v2
이런식으로 URL을 아예 분리해버려요
이게 첫번쨰 틀린방법
두번째 틀린방법은
URL은 똑같이 유지가 되요
똑같애, 버전1이든 버전2든
그 대신에
이제 Request를 보낼 때 헤더를 만들잖아요. 보통
헤더에다가
자기만의 엔트리(entry)를 넣는거에요
그래서 그사람(트로이 헌트) 예로는
API 마이너스 버전 후에 콜론(api-version:) 그게 이제 키 밸류 페어니까
거기다가 이제 2, 3(api-version:2, api-version:3) 이런식으로
그럼 서버에서 그 버전을 읽고
그 버전에 맞는 함수를 호출해서 결과를 반환한다죠
재밌는거는
만약에 버전이 없으면 어떻게 하냐
그러면 이제.. 최신버전으로 가정을 하는 거에요
아무래도.. 예전버전을 쓰는 사람이 아닌 최신버전을 쓸테니까
그런식이고
세번째 방법은
HTTP 헤더에 보면은 Accept 헤더가 있어요
내가 이제 호출을 할 때 서버에다가
내가 받을 수 있는.. 처리할 수 있는 파일은 제이썬(json)이야
아니면 엑스엠엘(xml)이야
아니면 뭐 텍스트야
이미지야.. 이런걸 얘기해 줄 수 있거든요
그럼 예를 들어 제이썬(json)을 받는다고 한면
accept하고 뭐 하고 애플리케이션 슬래쉬 제이썬인가 그럴거에요(application/json)
그 헤더 이름이
헤더 벨류(value)가
그럼 그걸 넣고, 플러스 v2 이런식으로 해 놓고
서버에서 그거를 본 다음에
그거를 커스텀 프로세싱 해갖고, 돌려준다 이건데 이게 세번째 틀린방법
그래서 각 방법마다 장점과 단점이 있어요. 당연히.
아니, 정확히 말하면 각 방법에 단점이 있어요 그래서 다 틀린방법이라고 하는건데
어느것도 확신하기 옳지는 않고
그냥 좀.. 종교전쟁 쪽으로 가고 있어요 사실은(웃음)
이게 맞다 저게 맞다. 이론적으로 논리적으로 외치고
어느 하나도 깔끔한 답이 없는 상황인데..
그래서 이제 제가 아까도 말했듯이 자기 회사에서 만든 규약을 정해놓고 따라가면 좋다고하는게 그거고
제가 택한 방법은 두번째 방법이에요
두번째 방법이 뭐였냐하면은
새로운 헤더를 넣는거에요
있던 헤더를 고치는게 아니라 그냥 API 버전2, 3 이런식으로
왜냐하면은, 일단 URL이 바뀌지 않으니까
뭐 심지어는 그 URL 만약 API가 아니라 웹사이트 URL이 되더라도
URL이 바뀌지 않으니까 search optimization(검색 최적화) 절대 안깨지고
API URL이 바뀌지 않으니까 코드가 바뀔일은 거의 없지만 헤더만 업데이트 하면 되는거죠
그냥 더 깔끔한거 같아요. 왜 버전이라는게
클라이언트가 눈에 보이게 해야되는지
이거는 그냥 뒤에서 숨겨갖고 난 버전 이거야 이런 개념이 맞는거 같거든요
그래서 그거고
이제 첫번째 방법, v1, v2, v3 쓰는거
RESTful 자체 개념하고 좀 어긋나는거 같긴 해요
왜냐하면
RESTful의 말그대로
내가 어떤 데이터를 받아오냐, 내가 필터해서 어떻게 다운으로 내려가냐 인데
그게 버전이란 개념은 별 의미가 없거든요
오히려 그 버전 넘버가 뒤에 나와갖고 필터링하면 모를까
그 버전이라는게 좀 해키(Hacky)한거 같고
마음에 그닥 들지 않는거
버전을 헤더로, 아니 URL로 박아두면은
서버를 두개를 띄울 수는 있겠죠 이 버전은 일로가고 이 버전은 절로 간다 이런식으로
나중에 그 버전 디프리케이트(deprecate) 시킬 때는 그냥 서버를 지워버리면 되니까
그런 장점도 있긴 해요 사실은
근데 그냥 눈에 깔끔해보이지 않는게 싫었고
두번째는 눈에 깔끔해보이고, 필요한거 뒤에서 매직 다 하고
이제 한 가지 오버헤드는
서버 자체에 라우팅이 있어야하는거죠
그 서버 코드에
이게 v1이고 v2면 이거호출 저거호출 저거호출.. 반환.. 이런식으로 와야하니까
그게 조금 단점이에요
또 하나의 단점은 그거일 수 도 있겠다. 이제
웹 API 같은 경우에서, ASP.NET 웹 API에서
라우팅, 커스텀 라우팅을 다 하거든요
그럼 거기다 이렇게,  온갖 규칙을 정해줄 수가 있는데
그, 패러미터(parameter)가
추가 되는 거를..
막, 널러블(nullable) 이런식으로 넣어갖고
삭제되는걸 nullable  이렇게 넣어서 처리해야되는 단점도 있네요..(시무룩)
그거는 좀 단점일거같긴해요. 오히려 API가 확 바뀔때는
차라리 v1, v2를 박는게 훨씬 나을수도 있어요
다시 원래대로 돌아가서 좀 생각을 해봐야겠네요(웃음)
그래서 이제 세번째 방법은
억셉트 헤더에(accept header)에 뭔가를.. 바꾼다거 자체가 좀..
뭐랄까.. 굉장히 기존에 있던걸 핵(Hack)하는 기분이고
나중에 이게 서버처리가 아니라 이미 저장된 파일로 호출할려고 할때도 또.. 애매해지고
뭐 그런.. 여러가지가 있죠
세번째는 정말 해키(Hacky)한거같아서 싫고
두번째나 첫번째인데..
두번째 첫번째 둘 다 장단점이 있어요
두번째가 좀 더 깔끔해보인다 URL을 볼때는
근데 이제 아까 말했듯이 Attribute routing(애트리뷰트 라우팅)
컨트롤러 위에다가 애트리뷰트 박아갖고 할 수 있는거..
URL 이렇게 적어줄 수 있는거(커스텀 라우팅)
그 부분에서의 약간의
단점이 있겠는데(심각)
뭐 어떻게 생각을 하면은 새로운 URL이 생기거나 있던  URL이 지워지는거라면
그건 버전의 문제가 아니라 그냥 새로운 URL이기 때문에 문제가 없을 수도 있겠네요.
지금 막 든 생각이에요, 좀 더 생각을 해볼거 같은데
일단 지금까지 든 생각으로는
저는 두번째 방법이 가장 깔끔해요
URL은 절대 바뀌지 않고
단지 accept, accept에서 바꾸는것도 아니고
그냥 API버전이라는 새로운
헤더에 키밸류 페어를 넣어서 거기에 버전을 넣고 서버에서 처리해주기
제가 봤던 트로이 헌트 아저씨.. 블로그를 제가 뭐
링크를 걸 수 있으면 아래다 링크를 걸든가 할게요
영어, 영문으로 되있지만.
예제가 이렇게 나와있어요. 뭐가 문제고, 뭐가 문제가 아닌지.
제가 스스로 찾아낸 결과가 아니라
좀 껄끄럽다 하다가
트로이 헌트 아저씨가 쓴거 보고, "아 이거 괜찮다. 이렇게 가야됐다." 라고 생각한거를
그냥 소개하고 싶었죠. 한마디로
"무논리 서치"(웃음)
포프였습니다