API 개발에만 신경을 쓰다보니 문서화에 너무 소홀했다.
이제 클라이언트 개발자들이 API연결을 하는데
URL이 너무 REST한 느낌이 아닌 거 같아서(사실 REST한 느낌이 뭐지 모르겠다)
한번 조사를 해보고 적용해보기로 했다.
Rest한 API란?
Rest에 있어서 중요한 것은 "언어에 독립적, 그러니 특정 기술이나 플랫폼에 얽매이지 않는다"인 점이라고 한다.
특히 '단순함'이 핵심인데, 데이터 포맷으로는 브라우저 간 호환성이 좋은 JSON을 사용한다. 이를 위한 원칙들이 있다.
1) 클라이언트-서버
클라이언트- 서버 아키텍처에선, 클라이언트가 리소스에 대한 요청을 보내고 DB와 직접적인 연결을 맺지 않는다. 서버는 사용자 인터페이스에 대해서 관여하지 않는다.
2) 균일한 인터페이스
이를 위해서 4가지 원칙이 있다.
- 자원 식별 : 각 리소스에는 리소스 상태와 독립적인 ID가 있어야 한다.
To have a uniform interface, multiple architectural constraints are required to guide the behavior of components. Additionally, resources should be unique so they are identifiable through a single URL.(URL을 통해서 리소스가 식별 가능해야 한다는 의미다)
- 표현을 통한 자원 조작 : 클라이언트가 갖고 있는 리소스 표현에는 리소스를 삭제하거나, 필요한 데이터가 포함된다.
- 자기 설명 메시지: 수신자가 이해할 수 있도록 모든 메시지가 포함돼 있으므로, 별도의 메시지가 필요하지 않는다.
- 서버는 하이퍼 링크를 사용해서, 클라이언트에게 사용 가능한 리소스를 알려줘야 한다. 클라이언트가 서버 내부에 대해 알 필요가 없다.
3) 상태 비저장
서버에 클라이언트에 대한 데이터가 포함되지 않고, 요청 처리에 필요한 모든 정보가 request에 포함된다.
4) 캐시 가능
각 응답에는 캐시 가능 여부와 응답을 캐시할 수 있는 기간을 알려주는 정보가 필요하다.
5) 계층화된 시스템
클라이언트는 서버에 직접 연결돼 있는지, 역방향 프록시 또는 로드 밸런서와 같은 중계 서버에 연결돼 있는지 알 필요가 없다. 중개 서버는 확장성을 개선하고, 서버가 비즈니스 로직만 담당하도록 할 수 있다.
그럼 SOAP은 뭐야?
SOAP(Simple Object Access Protocol)이란 프로토콜도 있는데, 보안이나 메시지 전송에 있어서 Rest보다 더 많은 표준이 정해져 있어서 더 복잡하다. 표준들로 인한 오버헤드가 커질 수 이씨잠ㄴ, 보안/트랜잭션/AICD 등을 준수해야 하는 종합적인 기능이 필요하다면 적합한 방식이 될 수 있다.
SOAP은 웹 방식에서는 적절하지 않고, 기업용 애플리케이션 등을 작업하는 데 더 이상적이다.
SOAP은 프로토콜이고, REST는 HTTP 프로토콜 기반의 가이드라인이다. REST는 JSON을 사용하기 때문에 페이로드(데이터 전송)의 무게를 가볍게 할 수 있다.
SOAP은 XML에만 의존한다. SOAP은 WS-security를 지원하는데, 이는 전송 레벨에서 보안이 아주 뛰어나며 ssl보다 조금더 복잡하기 때문에 기업ㅂ용 보안 도구를 통합하는데 이상적이라고 한다.
SOAP은 서버와 매우 긴밀하게 연결되기 때문에 그 통신 방식이 매우 엄격하고, 수정이나 업데이트하는 것이 어렵다.
흐름을 좀 살펴보자
-
2000년대 초반까지는 개발자들이 SOAP을 사용하면서, XML문서를 직접 작성하고 RPC(Remote Procedure Call)을 본문에 포함했다고 한다. 특정 엔드포인트를 지정하고 SOAP envelope(XML을 감싸는 구조)를 post 방식으로 전송했다. 매우 복잡하고 엄격한 규칙이 많았고, 디버깅도 어려웠다고 한다.
-
Roy Fielding을 중심으로 한 개발자 그룹이 새로운 표준을 만들기로 결정했다. 어떤 서버든 다른 서버와 쉽게 통신할 수 있는 방법을 만들기로 한 거싯이다. 단순하고 보편적인 규칙들 덕분에 개발자들이 필요한 소프트웨어를 쉽게 통합할 수 있게 됐다.
그러면 Rest한 API를 어떻게 사용해?
-
클라우드 환경에 적합하다. 아키텍처가 무상태 기반으로 짜여져 있기 때문에, 하나의 서버에 문제가 있더라도 다른 서버에서 요청을 처리할 수있다. 특히 애플리케이션 단위로 서버를 쪼개더라도 무리없이 처리가능하다.
-
Rest한 아키텍처는 클라이언트 사이드에 의존적이지 않다. 그러므로, 웹기반/iOS/Android/IoT 서비스 등 다양한 클라이언트 사이드와 연동이 가능하다.
Rest하면 무조건 좋은거야?
- API간 일관성을 지키기 쉽지 않다는 것
- 인가 작업이 복잡하다는 것이다(api key방식, OAuth 방식)
- security가 철저하게 보장되지 않는다(적절한 인가방식이 업고, rate limiting이 되지 않으며, 데이터 암호화를 보장하징 ㅏㄶ는다)
