REST API로 전환하면 "앱" 은 괜찮나요?
몇년 전에 서버 개발자가 질문을 이런 질문을 한 적이 있다.
REST API로 전환하면 "앱" 입장에서는 괜찮은가요?
서버에서 REST API를 적용해보자는 말이 나왔기 때문이었다.
혹시 앱에서 할 일이 더 많아지는 건 아닌지, 아니면 앱에서 관리가 더 쉬워지는지 물은 것이었다. 나는 어쩐지 앱 입장에서 장단점을 이야기해야 할 것 같았다. 그런데 그런 지식은 내머릿속에 없었다.
그동안 나는 서버에서 주는 API 명세만 있으면, 명세대로 데이터를 요청하고 받았다. 같은 회사의 서버 뿐 아니라, 필요에 따라 다른 팀이나 오픈 API를 사용하는 일도 있었기에 그 중에는 분명 REST API도 있었다. 하지만 나는 API 의 형태나 방식을 따지고 구분한 적은 없었다. 서버 개발자가 물어보기 전까지 나는 말그대로 주는 대로 받아왔다.
당시 나는 앱은 서버에서 주는 대로 받으니, 서버에서 편한대로 개발해서 알려달라고 대답했다.
근래 RESTful API Design - Step By Step Guide라는 글을 접한 뒤로 그 때 생각이 나서 REST API에 대해 앱개발자 입장에서 정리해봤다.
REST
REST (REpresentation State Transfer) 하이퍼 미디어를 전송하기 위한 소프트웨어 아키텍쳐 중 하나이다. HTTP(HyperText Transfer Protocol)의 주요 저자인 Roy Fielding이 200년 박사학위 논문(Architectural Styles and the Design of Network-based Software Architectures)에서 소개했다.
RESTful
REST에는 6가지 제약사항이 있고, 이를 모두 만족하는 API를 RESTful API라고 한다.
REST의 6가지 제약사항 (6 guiding constraints)
1. Client-Server : UI와 데이터(data storage)를 구별해서 클라이언트와 서버가 독립적으로 구성될수 있도록 한다.
2. Stateless : Session state와 관련된 정보는 클라이언트에서 관리하고, 서버와 따로 주고 받지 않는다.
3. Cacheable : 클라이언트는 동일한 요청에 대해 캐싱해둔 데이터를 재사용할 수 있다. 응답(response)에 cacheable 혹은 non-cacheable 라벨을 지정해서 캐시 여부를 표기 한다.
4. Uniform interface : 여러 시스템에서 리소스를 일관된 형태로 표현하기 위해서 인터페이스 제약이 필요하다. REST에서 일관된 인터페이스를 위해 4가지 조건이 존재한다.
- 자원의 식별(identification of resources),
- 메시지를 통한 리소스의 조작(manipulation of resource through representations),
- 자기서술적 메시지(self-descriptive messages),
- 애플리케이션의 상태에 대한 엔진으로서 하이퍼 미디어(hypermedia as the engine of application state)
5. Layered system : 클라이언트는 한 대의 서버와 통신하듯이 통신하지만, 서버는 계층 구조로 구성되어 실제로는 여러대의 서버로 부터 데이터를 구성한다.
6. Code on demand(optional) : 클라이언트는 자바 애플릿이나 자바 스크립트를 다운 받아서 실행 할 수 있다.
HTTP 와 REST
HTTP는 통신 프로토콜이고, REST는 아키텍쳐이다. HTTP로 전달할 데이터를 잘 담기 위한 방식 중 하나가 바로 REST이다.
REST API로 전환하면 앱은 괜찮나요? - 이제와서 하는 대답
여전히 상관없다. 서버에서 편한대로 개발해달라.
REST API로 전환된다면, 앱 입장에서도 분명 장점은 존재한다. 호출하는 API의 형식이나 응답으로 부터 데이터를 추출하는 방식에 보다 일관된 규칙을 적용할 수 있으니 코드가 줄어들 가능성이 있고, 불필요한 데이터 사용을 줄일 가능성도 있다. 하지만 개인적으로는 여전히 서버가 주는 API 명세가 명확하다면, REST든 아니든 앱을 개발하는 데에는 큰 문제가 되지 않는 것 같다. API 형식이 아니라 개발자 간 활발한 논의와 원만한 협의로 통일된 인터페이스를 이끌어내는 것이 중요한 것 같다.
REST API에 대해 생각해보게 한 글(RESTful API Design - Step By Step Guide)에서 접한 아마존 성공의 핵심 전략에서도 개발의 자유와 협업이 보였다. 정돈된 인터페이스를 통해 소통하며 개발한 결과가 아닐까...
Jeff Bezos'(Amazon 설립자) Mandate (아마존 성공의 핵심 전략)
1. 모든 팀은 각팀의 데이터와 기능을 서비스 인터페이스로 노출한다.
2. 각 팀에서 노출한 인터페이스를 이용해서만 통신 하도록 한다.
3. 다른 방식(다른 팀의 데이터에 직접 접근, 연결, 혹은 공유 데이터 모델 등)으로 상호작용하는 것은 허용하지 않는다. 네트워크를 통해 서비스 인터페이스를 호출하는 것만이 유일한 통신 방법이다.
4. 어떤 기술을 사용해도 상관 없다. HTTP, Corba, Pubsub, 커스텀 프로토콜 등. 전혀 문제 되지 않는다.
5. 모든 서비스 인터페이스는 예외없이 외부에 노출할거라는 가정하에 설계되어야 한다. 즉, 외부 개발자에게 노출 할 인터페이스라고 생각하고 설계해야 한다. 예외는 없다.
6. 이를 지키지 않을 시에는 해고.
References
https://ko.wikipedia.org/wiki/REST
https://restfulapi.net/
https://betterprogramming.pub/restful-api-design-step-by-step-guide-2f2c9f9fcdbf