안녕하세요. 이사작전.com의 말랑고양입니다. 오늘은 REST API라는 주제로 포스팅을 하려합니다. REST라는 단어는 웹개발자라면 누구나 알면서도 누군가에게 설명하기 참 어려운 것 같습니다. 그 이유를 조심스럽게 예측해보자면 "현재 REST란 개념이 난립되어 있는 것이 아닌가?" 라는 생각이 듭니다. 따라서, 이 포스팅은 REST의 개발자 로이필딩을 기준으로 작성되려합니다.
현재, 개발자들이 말하는 REST하고
REST의 개발자 로이필딩이 말하는 REST하고 차이가 큽니다.
"Please try to adhere to them or choose some other buzzword for your API" - 로이필딩
규칙을 하나라도 지키지 않았다면, REST라고 부르지 마라.
REST란?
한 문장으로 설명 : 어떻게 하면 웹을 망가뜨리지 않고 진보시킬 수 있을까? 에 대한 해답입니다.
웹 페이지를 변경했다고 웹 브라우저를 업데이트하지 않는 것을 상식으로 만든 소프트웨어 아키텍처입니다. 규칙을 전부 지킨 api를 REST API라고 부르고 규칙을 하나라도 빠뜨렸을 경우 REST라고 부르지 않습니다. 웹의 독립적인 진화를 위해서 만들어졌고 그것을 명백하게 성공시켰습니다.
마이크로 소프트가 2016년에 microsoft REST API Guidelines라는 문서를 발표했습니다. 개발자들의 입장에서는 상당히 합리적이라고 보였던 것 같습니다만, 로이필딩은 "이거 REST가 아닙니다"라고 직접 말하기도 하였습니다.
원론적으로 돌아와서 REST의 규칙이란 무엇일까?
1. client-server
2. sateless
3. cache
4. layered system
대체로 잘 지킬 수 있음
HTTP만 잘 따라도 다 지킬 수 있음.
5. uniform interface
이것을 대부분 지키지 못함.
6. code-on-demand (optional)
서버에서 코드를 클라이언트에 보내서 실행할 수 있어야한다. = javascript를 얘기함
위의 규칙을 조금만 더 자세히 알아보자.
1. client-server : 클라이언트-서버 스타일은 사용자 인터페이스에 대한 관심(concern)을 데이터 저장에 대한 관심으로부터 분리함으로써 클라이언트의 이식성과 서버의 규모확장성을 개선한다.
2. sateless : 클라이언트와 서버의 통신에는 상태가 없어야한다. 모든 요청은 필요한 모든 정보를 담고 있어야한다. 요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고, task 실패시 복원이 쉬우므로 신뢰성이 개선되며, 상태를 저장할 필요가 없으므로 규모확장성이 개선된다.
3. cache : 캐시가 가능해야한다. 즉 모든 서버 응답은 캐시 가능한지 그렇지 아닌지 알 수 있어야한다. 효율, 규모확장성, 사용자 입장에서의 성능이 개선된다.
4. layered system : – 계층(hierarchical layers)으로 구성이 가능해야하며, 각 레이어에 속한 구성요소는 인접하지 않은 레이어의 구성요소를 볼 수 없어야한다.
5. uniform interface : 구성요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)해야한다. 인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호작용의 가시성이 개선되며, 구현과 서비스가 분리되므로 독립적인 진화가 가능해진다. 이 스타일은 다음의 네 제약조건으로 이루어진다: identification of resources, manipulation of resources through representation, self-descriptive messages, hypermedia as the engine of application state
6. code-on-demand (optional)
서버에서 코드를 클라이언트에 보내서 실행할 수 있어야한다. = javascript를 얘기함
개발자들이 가장 잘 지키지 못하는 규칙. uniform interface?
uniform interface는 대부분 개발자들이 잘 지키지 못하는 규칙입니다. 우선 어떤 세부사항이 있는지 알아보겠습니다.
1. identification of resources
2. manipulation of resoruces through representations
3. self-descriptive message
4. hypermedia as the engine of application state(HATEOAS)
uniform interface > identification of resources
리소스가 URL로 식별되면 된다.
uniform interface > manipulation of resoruces through representations
HTTP메세지에 CRUD를 수행하는 것을 표현하자.
uniform interface > self-descriptive message
메시지는 스스로를 설명해야한다.
- 목적지가 표현되어야 한다.
- Content-Type이 명확히 표현되어야 한다.
- media type을 정의해야 한다.
json의 경우 media type을 지키기 어려운 이유는 아래와 같습니다.
[{"id": "yhsang2", "pwd": "123"}]
사람은 id와 pwd라는 키(key)를 보면 회원정보 값이 담겨있겠구나 짐작할 수 있지만, 기계는 그렇지 않습니다. self-descriptive message 즉, 메세지는 자기 스스로를 정확하게 설명할 수 있어야 됩니다. 명세서에 위 키 값들을 잘 정의해서 링크를 걸면됩니다. ex) <link rel="profile" href="http://test.com/profile" />
uniform interface > HATEOAS
하이퍼링크를 통한 다음 상태로 전이
ex) a태그를 이용해 표현된 링크를 통해, 다음 상태로 전이될 수 있다.
REST API란?
REST 아키텍쳐 스타일을 따르는 API입니다.
RESTful API란?
REST 규칙을 잘 지킨 시스템을 RESTful하다고 표현합니다만, 잘못된 표현입니다.
REST API라고 표현하면 됩니다. 왜냐하면, REST의 규칙을 하나라도 어긴 시스템을 REST라고 부르지 않기 때문입니다.
"Please try to adhere to them or choose some other buzzword for your API" - 로이필딩
규칙을 하나라도 지키지 않았다면, REST라고 부르지 마라.
감사합니다.
[본문을 인용할 경우, 출처를 꼭 남겨주세요]
[저작권자 ⓒ 플랫폼공작소, 무단 전재 및 재배포 금지]
