Restful API 란?
- Restful API 는 서버와 클라이언트 간 통신 방식 중 하나로, 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스
- 이름 그대로 Rest 스러운 API. 즉, REST 아키텍처 스타일로 클라이언트와 서버가 요청과 응답을 하는 웹 API
REST 란?
월드와이드웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식.
REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처
탄생 배경
-
REST 아키텍처는 2000년 로이 필딩이라는 컴퓨터 과학자에 의해 탄생한 개념.
로이 필딩은 HTTP 1.0, 1.1 의 설계자로서 HTTP 프로토콜을 통한 웹 표준화에 엄청난 기여를 했다. -
단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응할 수 있어야 한다. 따라서 플랫폼에 맞추어 새로운 서버를 만드는 수고를 들이지 않기 위해 범용적으로 사용성을 보장하는 서버 디자인이 필요하게 되었다.
-
로이 필딩은 그 당시 웹 설계의 우수성에 비해 제대로 사용되지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST 를 발표했다.
더 알아보자
위의 API 들은 무엇을 의미할까?
첫 번째 API 는 아마도 안드로이드 크루들의 정보를 가져오는 API,
두번째는 마지막에 id 가 적혀있는 것으로 보아 안드로이드 크루 중 id가 1인 크루의 정보를 가져오는 API,
마지막은 안드로이드 크루 중 id가 1인 크루의 정보를 삭제하는 API 일 것이다.
메시지만 봐도 이 API 가 어떤 동작을 할지 예상이 가능하다.
이것은 RESTFUL API 의 가장 큰 특징으로, REST 아키텍처를 준수한 RESTFUL API는 요청 메시지만 보고도 무엇을 원하는지 파악이 가능하다!
REST 란 무엇일까
- Representational State Transfer 의 약자.
- 표현 / 상태 / 전달로 해석되며, 의역하면 자원을 이름(표현)으로 구분하여 자원의 상태(정보)를 저장하는 것을 뜻한다.
구성요소 - 자원
- REST 에서는 자원을 표현할 때 URI 를 사용하여 표현한다. URI 는 자원을 구분하고 처리하기 위해 사용한다.
ex) /books, /customers - URI 는 싱글톤이나 컬렉션으로 표현할 수 있다. (싱글톤: /customer, 컬렉션: /customers)
- URI 는 서브 컬렉션을 포함할 수 있다. 예를 들어 특정 고객의 계좌에 접근하려고 할 때
/customers/1/accounts 로 표현할 수 있다. -> customers 하위에 accounts 라는 서브 컬렉션을 넣어서 특정 고객의 계좌라는 것을 명시할 수 있다. - REST 에서 말하는 URI 규칙을 살펴보자. URI 의 리소스는 명사를 이용해서 표현해야 한다. 아래처럼 자원의 처리에 대한 행위를 URI 에 나타내지 않는다.
< BAD EXAMPLE >
행위는 URI 에 넣는 대신 요청 메시지에 HTTP 메소드를 사용하여 내부적으로 전달하는 것을 원칙으로 한다.
< GOOD EXAMPLE >
cf. URI 와 URL
URI 는 URL과 URN 을 포함하고 있다.
URI - 자원의 식별자
URL - 위치, 즉 네트워크 상에서 자원이 어디 있는지 위치를 알려주기 위한 규약
예를 들어 http://www.naver.com/index.html?page=1232950&id=776 링크가 있다고 하자.
http://www.naver.com/ 서버에 위치한 index.html 페이지는 query string인 page의 값에 따라 여러가지 화면 결과를 나타나게 된다.
이때 여기서 URL은 index.html의 위치를 표기한 http://www.naver.com/index.html 까지이다.
하지만 사용자가 원하는 정보에 도달 하기위해서는 ?page=1232950&id=776라는 식별자(Identifier)가 필요한 것이다.
따라서 엄격히 구분하자면 위의 http://www.naver.com/index.html?page=1232950&id=776 주소는 URI이고, 식별자가 빠진 http://www.naver.com/index.html를 URL이라고 하는 것이다.
구성요소 - 행위(상태)
REST 에서 자원에 대한 모든 행위는 HTTP METHOD 로 표현한다.
HTTP METHOD 에는 GET, POST, PUT, PATCH, DELETE 등이 있다.
HTTP METHOD 는 리소스에 대해 수행해야 하는 작업을 서버에 알려준다. 서버는 HTTP METHOD 에 따라 리소스에 대한 작업을 수행하게 된다.
- GET: 자원을 검색할 때 사용
- POST: 자원을 생성할 때 사용. 보통 body 와 함께 이루어짐
- PUT: 자원을 업데이트할 때 사용. 보내지 않은 정보는 null 값으로 업데이트
- PATCH: 자원을 업데이트할 때 사용. 보내지 않은 정보는 기존 정보를 유지
- DELETE: 자원을 삭제할 때 사용
구성요소 - 표현
표현이란 클라이언트가 전달받고자 하는 형식을 지정한다는 의미이다.
보통 클라이언트 요청 헤더를 통해 구현이 된다.
Accept 헤더를 이용해 응답 타입을 지정해줄 수 있다.
EX) Accept: image/png, Accept: text/html
REST 에서는 기존 우리가 알고있던 HTTP 통신 방식을 다음과 같이 해석한다.
클라이언트는 원하는 자원가 그 표현을 요청하고 서버는 표현을 선택해서 전송한다.
서버는 자원이 아닌 자원의 표현을 응답으로 보낸다.
설계 원칙
- Uniform Interface: 모든 RESTful 웹 서비스 디자인의 기본. 이는 서버가 표준 형식으로 정보를 전송함을 나타낸다. 형식이 지정된 리소스를 REST에서 표현이라고 부른다. 이 형식은 서버 애플리케이션에 있는 리소스의 내부 표현과 다를 수 있다. 예를 들어, 서버는 데이터를 텍스트로 저장하되, HTML 표현 형식으로 전송할 수 있다.
- Stateless(무상태): REST 아키텍처에서 무상태는 서버가 이전의 모든 요청과 독립적으로 모든 클라이언트 요청을 완료하는 통신 방법을 나타낸다. 클라이언트는 임의의 순서로 리소스를 요청할 수 있으며 모든 요청은 무상태이거나 다른 요청과 분리된다. 이 REST API 설계 제약 조건은 서버가 매번 요청을 완전히 이해해서 이행할 수 있음을 의미한다.
- Layered System(계층화 시스템): 계층화된 시스템 아키텍처에서 클라이언트는 클라이언트와 서버 사이의 다른 승인된 중개자에게 연결할 수 있으며 여전히 서버로부터도 응답을 받는다. 서버는 요청을 다른 서버로 전달할 수도 있다. 클라이언트 요청을 이행하기 위해 함께 작동하는 보안, 애플리케이션 및 비즈니스 로직과 같은 여러 계층으로 여러 서버에서 실행되도록 RESTful 웹 서비스를 설계할 수 있습니다. 이러한 계층은 클라이언트에 보이지 않는 상태로 유지된다.
- Cacheable(캐시 가능성): RESTful 웹 서비스는 서버 응답 시간을 개선하기 위해 클라이언트 또는 중개자에 일부 응답을 저장하는 프로세스인 캐싱을 지원한다. 예를 들어 모든 페이지에 공통 머리글 및 바닥글 이미지가 있는 웹 사이트를 방문한다고 가정해 보자. 새로운 웹 사이트 페이지를 방문할 때마다 서버는 동일한 이미지를 다시 전송해야 한다. 이를 피하기 위해 클라이언트는 첫 번째 응답 후에 해당 이미지를 캐싱하거나 저장한 다음 캐시에서 직접 이미지를 사용한다. RESTful 웹 서비스는 캐시 가능 또는 캐시 불가능으로 정의되는 API 응답을 사용하여 캐싱을 제어한다.
- 온디맨드 코드: REST 아키텍처 스타일에서 서버는 소프트웨어 프로그래밍 코드를 클라이언트에 전송하여 클라이언트 기능을 일시적으로 확장하거나 사용자 지정할 수 있다. 예를 들어, 웹 사이트에서 등록 양식을 작성하면 브라우저는 잘못된 전화번호와 같은 실수를 즉시 강조 표시한다. 서버에서 전송한 코드로 인해 이 작업을 수행할 수 있다.
다섯가지의 설계원칙이 있지만 Uniform Interface 를 제외한 나머지 제약사항은 HTTP 프로토콜을 이용하는 것 만으로도 지켜질 수 있는 제약사항들이다. 따라서 개발자들이 api 설계 시 Uniform Interface 원칙을 지키는 것에 집중을 해서 구현을 하면 된다. 더 자세한 Uniform Interface 설명은 여기서
마무리
이 게시물에서 다룬 개념은 로이필딩의 180쪽짜리 논문의 일부분만 정리한 것이다.
로이필딩은 REST 아키텍처 스타일에 제시된 제약조건들을 모두 따라야 Restful API 라고 말한다.
그러나 사실 오늘날의 대부분의 api 는 REST를 모두 준수하지는 않는다.
로이필딩은 애초에 레스트는 비효율적이라는 말과 함께 다음과 같은 말을 남겼다. “ 시스템 전체를 통제할 수 있다고 생각하거나, 진화에 관심이 없다면 REST에 대해 따지느라 시간을 낭비하지 마라“
Rest 를 꼭 전부 따라야하는것은 아니다. 모든 원칙을 지켜 레스트풀한 에이피아를 개발할지, 레스트 원칙 중 지킬 수 있는 부분 필요한 부분만 적용할것인지는 APi를 설계하는 이들이 자신의 상황에 맞게 스스로 판단하여 결정하면 된다고 생각한다.
참고 링크
