REST 연구 요약본
REST에 관해 연구했던 내용을 공개하고 가장 많이 받은 피드백은,
‘간단히 말해보라’는 것이었다.
간단한 문제가 아니라서 여전히 간단히는 말할 수는 없지만,
널리 퍼지기 좋게 몇 가지 문장으로 (자극적으로!) 정리할 필요를 느꼈다.
이 글 조차도 다 읽지 않고 비판하는 사람이 많을 것을 알고 있지만,
- “뭘 그렇게 복잡하게 생각해? 피곤한 친구구만”
나는 계속 REST라는 용어를 함부로(!) 쓴다고 해서 비난하지 않는다.
REST라는 용어를 쓰지 말라고도 하지 않고, 잘못 썼다고 그 사람을 폄하하지도 않는다.
어느 누구도 설득하고 싶지 않다.
다만 REST가 우리에게 주는, 변화와 확장에 대응하라는 교훈을 좀 더 알리고 알리고 싶다.
연구했던 내용을 짧게 줄여 한장에 정리해보겠다.(이미 글이 길어진 기분이지만..)
중간 중간 아래 연재 목록에 어떤 내용이 담겨 있는지 설명한다.
- REST - 긴 여정의 시작
- REST - HTML Form에서 GET/POST만 지원하는 이유
- REST - 논문(요약) 훑어보기
- REST - REST 좋아하시네
- REST - Roy가 입을 열다
- REST - 당신이 만든 건 REST가 아니지만 괜찮아
- REST - 논문 읽기(To Do)
REST
Roy T. Fielding
Senior Principal Scientist at Adobe, co-founded Apache, authored the REST architectural style and Web standards for URI, HTTP/1.x, and URI Templates.
온라인에서 보게되는 RESTful API라고 부르는 것 대부분은 로이 필딩의 의도에 반한다.
- 그가 만들었으니 그가 옳다!
몇 가지 잘못 사용되는 수준이 아니라 반대 방향을 바라보고 있다.
2008년 로이 필딩은 블로그에서 이에 관해 비판했지만, 육아를 시작한 후로 더 이상 이야기가 없다. (트위터에선 여전하시다)
2008년에 로이가 한 이야기를 해석해 본 것이 - 5. REST - Roy가 입을 열다
REST는 어렵다
사람들은 REST가 구현하기 어렵다고 하는데,
- HTTP를 HTML form에서 다루기 힘들거나
- RPC에 어떤 메소드를 써야할 지 모르거나
- 어떤 응답코드를 써야할 지, 응답코드가 무슨 의미인지 모르거나
- 복잡한 기능을 명사로 표현하기 어렵기 때문인 것 같다
이런 건 REST의 문제가 아니다. 단지,
- HTTP를 이해 못했거나
- 리소스를 잘못 설계했거나
- 당신의 API가 RESTful할 이유가 없거나
사람들의 오해를 단적으로 보여주는 글을 읽고, 여기 달린 100여개의 댓글을 번역하고 정리한 것이 - 4. REST - REST 좋아하시네
그렇다고 REST가 쉽다는 건 아니다. 로이 필딩은 논문이 전문가를 위한 것이라고 언급했다.
논쟁에서 가장 흔히 등장하는 이야기가 Form에서 GET, POST만 지원해서 REST를 적용하기 어렵다인데, 이를 위해 특별히 2. REST - HTML Form에서 GET/POST만 지원하는 이유도 조사했다.
REST가 의미하는 것
REST가 최종적으로 추구하는 건 효율적이고 확장가능한 시스템이다.
이를 위해 6가지 제약조건(하나는 optional)을 제시했다.
조금 비약해서 소개하자면
- client-server로 나누어 UI와 data 저장에 대한 관심사를 분리하면 각기 독립적으로 진화할 수 있어서 좋고
- 시스템이 커져서 client가 많이 붙으면 서버가 일일이 관리하기 힘드니, payload에 필요한 모든 정보를 넣으면 한번의 요청/응답으로 관계를 정리할 수 있고
- 그럼 네트웍에 부하가 갈테니 캐시를 사용해야하고
- 복잡한 시스템으로 확장되면 구성요소간 커뮤니케이션에 문제가 생길 수 있으니 동일한 인터페이스를 써야하는데 4가지를 언급한다
- 리소스 식별 방법
- representation을 통한 제어
- 요청/응답에 필요한 모든 정보를 넣을 것
- 어플리케이션의 상태 변경이 hypertext로부터 발생하는 것
- 시스템이 커지면 중간에 방화벽이나 리버스 프록시같은 미들웨어가 필요하게 되는데 통신하는 client와 server는 이를 모르고 통신할 수 있어야 함
로이는 네트웍 기반의 효율적이고 확장가능한 시스템을 만들기 위해선 이 제약조건이 필요할 것으로 생각했고, 이 조건을 만족하면 REST한 시스템이라고 할 수 있다.
이 제약조건에 대해 더 자세히 설명한 것은 - 3. REST - 논문(요약) 훑어보기
그 많은 API가 RESTful하지 않은 이유
클라이언트와 서버가 지나치게 결합되어 있기 때문이다.
API 문서를 옆에 끼고 개발을 해야만 한다면,
API를 수정하려는데 클라이언트에 문제가 생기지 않을까 걱정을 하고 있다면,
UI와 백엔드가 독립적으로 진화할 수 없게 단단히 결합되었다고 볼 수 있다.
hypermedia as the engine of application state.
로이 필딩은 hypertext의 역할이 가장 중요하다고 강조한다.
response에 링크를 쉽게 추가해주는 ‘HATEOAS 지원 라이브러리’같은 것도 꽤 보이는데,
단순히 다른 페이지에 대한 링크를 추가하는 것 만으로는 부족하다.
사실 웹 문서가 아닌 바에야, 시스템 전체를 관통하는 인터페이스로써 hypertext를 설계하기가 쉽지 않다고 생각한다.
내가 이 부분을 명확하게 설명하기 위해선 사례 연구가 더 필요하다.
표준
로이는 요청/응답 트랜잭션 이외의 영역에서 의존해야할 정보가 있다면, 그건 표준이어야 한다는 생각인 것 같다.
세상엔 별별 표준이 다 만들어진다.
API를 내부 시스템으로 한정하면 독자적인 표준도 가능할 것이다.
ROA(Resource-Oriented Architecture)
그 똑똑한 개발자들 간 10여년이 넘는 시간 동안 용어를 잘못 쓰고 있는 이유는 나도 의아한데, ROA에서 그나마 원형을 발견할 수 있었다.
Leonard Richardson의 RESTful Web Services의 한국어 번역서은 절판 상태.
행복한 아빠님의 블로그에 정리된 게 있어서 참고했다.
마틴 파울러가 Richardson의 Maturity Model을 소개한 블로그를 썼는데, 지앤선 블로그에 번역이 되어있다.
REST에서 ROA로, 여기서 개발자들에게 전달되면서 소위 말하는 REST 규칙이 생겨난 것 같다.
가족오락관 게임처럼..
소위 REST라고 할 때 어떤 것을 떠올리는가?
- HTTP의 네가지 메소드를 CRUD에 대응하는 것
- HTTP의 응답코드를 200, 404, 500이 아닌 것으로 리턴하는 것
- URL을 계층적으로 구성하는 것
- 또 있던가?
하지만 지금 이 순간부터 REST라는 용어가 나타나면 유심히 살펴보자.
그 많은 REST라는 용어로부터 확신할 수 있는 형식이 무엇이 있는가?
‘CRUD를 위한 네가지 HTTP 메소드를 쓴다’정도?
루비 온 레일즈와 같은 프레임웍에서 이를 더 부추겼다는 의견도 있다.
당신이 만든 건 REST가 아니지만 괜찮아
하지만 난 당신의 API가 REST가 아니라 해도 괜찮다고 말해주고 싶다.
REST가 아니라도 실패한 디자인이 아니라고 말해주고 싶다.
난 RESTful API를 만들 생각은 ‘아직’ 없다.
- 면접을 본다면 RESTful API를 만들어봤다고 하겠지만 말이다
이런 이야기를 적은 것이 - 6. REST - 당신이 만든 건 REST가 아니지만 괜찮아
여기선 Your API isn’t RESTful — And That’s Good이라는 블로그의 내용을 번역했는데,
이런 혼란을 종식 시키고 RESTful 대신 RESOURCEful이라는 용어를 정의해서 모범 사례를 구축하자는 주장이다.
우리가 원하는 바로 그 API의 모습이 담겨있다.
최초 누가 주장했는지는 잘 모르겠지만 이 블로그는 2016년 초에 발행됐으며, RESOURCEful이라는 용어의 사용은 점점 증가하는 추세다.
Laravel의 문서에서도 5.3버전(2016년 9월)부터 RESTful이라는 용어가 제거됐다.
Moder PHP User Group 8월 발표자료
이 내용으로 8월달 MPUG 정기 모임에서 발표한 자료도 걸어둔다.