Intro
API 는 1. 서버가 클라이언트에 제공하는 것이고, 2. 리소스를 잘 활용할 수 있도록 제공하는 인터페이스입니다. 잘못 만들어진 API 는 클라이언트의 잘못된 사용을 이끌어내거나, 최악의 경우에는 사용하지 않는 경우로 이어집니다. 따라서 어떻게 오답을 피하고, 사용하기에 좋은 API 를 만들 수 있을지를 고민해야 하겠죠.
REST (REpresentational State Transfer)
REST 란 Representational State Transfer 의 약자로, HTTP 의 주요 저자 중 한 사람인 로이 필딩(Roy Fielding) 이 2000년에 발표한 그의 박사학위 논문에서 소개한 개념이라고 합니다.
위키백과에서는 REST 가 무엇인지를 다음과 같이 정의하고 있습니다.
엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 '네트워크 아키텍처 원리'란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.
초짜에게는 알 수 없는 단어들이 너무 많은데요. 저는 REST 를 웹의 장점을 최대한 활용하기 위해서 프로그래밍에 적용해야 할 규칙 또는 제약조건 이라고 이해했습니다. API 로 말하자면 RESTful 한 API 를 만들게 되면 오답을 피하고 더 나은 API 를 만들 수 있게 된다는 것이죠.
이 시스템의 열정적인 옹호자들은 스스로를 RESTafrians 라고 부른다고도 할 정도라고 하니, 이 방법이 무조건 정답이라고 할 수 없겠지만, 최소한 더 나은 방법을 고민하도록 돕는 개념인 것 만큼은 분명해보입니다.
RESTful API
그래서 정확하게 REST 가 뭔지, 또 RESTful 한 API 를 만들기 위해 따라야 하는 규칙이 무엇인지가 궁금한데요. 위키백과에서는 이 부분을 "REST 아키텍처에 적용되는 6가지 제한조건" 과 "REST 인터페이스의 원칙에 대한 가이드" 로 나누어서 설명하고 있습니다.
위키백과를 읽어도 딱 와닿는 느낌은 아니어서 찾다가 다음의 링크를 발견했습니다. 전반적인 설명이 되어있으니 참고하시면 좋을 것 같구요.
보시면 4번에서 가장 중요한 2 가지를 요약하고 있는데요.
첫 번째, URI는 정보의 자원을 표현해야 한다.
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
아무렇게나 만들 수 없어서가 아니라, 그렇게 하면 안 좋아질 수 있기 때문에 제약사항을 만들어두는 것이죠. 많은 사람들이 RESTful API 를 받아들여 사용하고 있기 때문에 더더욱 이런 규칙을 이해할 필요가 있는 것 같습니다. 링크의 4번에서 이어서 세부적인 것들을 설명하고 있기 때문에 쭈욱 읽어보시면 도움이 될 것 같습니다.
코드스테이츠 풀타임 코스를 수강하기로 마음 먹고 퇴사하기까지 딱 한 달쯤 걸렸었는데요. 후임자를 채용하는 데 시간이 오래 걸리기도 했고, 여러 사정으로 인수인계에는 이틀이란 시간만 주어졌습니다.
마침 혹시나 싶어 작성해 둔 업무매뉴얼이 도움이 많이 되었습니다. 누가 보더라도 충분히 이해할 수 있도록 작성하기 위해 여러 날을 고민했죠. 제 마음대로 작성할 수도 있는 것이지만, 후임자가 알아보지도 못하는 문서라야 작성할 필요가 없으니까요.
프로그래밍도 마찬가지라고 생각합니다. 개발자가 제일 고민하는 것이 변수명을 짓는 것이라는 밈을 본 적이 있는데요. 결국은 어떻게 하면 더 쉽고 빠르게, 또 정확하게 협업을 할 수 있을지를 고민하는 데서 출발하는 것 같아요. RESTful API 의 규칙도 이렇게 받아들일 수 있지 않을까 싶습니다.
