우선 RESTful을 알아보기전에 REST를 알아보자.
REST(Representational State Transfer)
즉, 대표상태전송이라고 한다.
웹이 HTTP의 설계 상 우수성을 제대로 사용하지 못하고 있는 상황을 보고 웹의 장점을 최대한 활용할 수 있는 아키텍쳐로서 REST를 소개했고 이는 HTTP 프로토콜을 의도에 맞게 디자인하도록 유도했다고 한다!
REST 개념
모든 리소스에 대해 고유의 URI을 부여한다.
HTTP Method를 이용해 CRUD 명령을 내림.
CRUD와 HTTP Method
CRUD
CREATE, READ, UPDATE, DELETE
HTTP Method
POST, GET, PUT, DELETE
이 부분에 대해서는 다른편에서 제대로 다루어보겠다.
어찌되었든 위에서 말한 대표 상태 전송 REST는 URI가 부여된 리소스의 상태를 응답으로 전송한다는 의미를 가지게 된다.
URL과 URI의 차이점은 또 다음편에 계속!
REST 구성 요소
응답상태 코드
1XX: Informational(정보 제공)
임시 응답으로 현재 클라이언트의 요청까지는 처리되었으니 계속 진행하라는 의미
2XX: Success(성공)
클라이언트의 요청이 서버에서 성공적으로 처리되었다는 의미
3XX: Redirection(리다이렉션)
완전한 처리를 위해서 추가 동작이 필요한 경우다. 주로 서버의 주소 또는 요청한 URI의 웹 문서가 이동되었으니 그 주소로 다시 시도하라는 의미
4XX: Client Error(클라이언트 에러)
없는 페이지를 요청하는 등 클라이언트의 요청 메시지 내용이 잘못된 경우를 의미
5XX: Server Error(서버 에러)
서버 사정으로 메시지 처리에 문제가 발생한 경우다 서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생하는 경우를 의미
REST 장/단점
장점 | 단점 |
---|---|
언어와 플랫폼에 독립적 | HTTP 프로토콜만 사용이 가능하다 |
SOAP보다 개발이 쉽고 단순하다 | p2p 통신 모델을 가정했기 때문에 둘 이상을 대상으로 하는 분산 환경엔 유용하지 않다 |
REST가 지원하는 프레임워크나 언어 등 도구들이 없어도 구현이 가능하다. | 보안, 정책등에 대한 표준이 없어 관리가 어렵다. |
HTTP를 그대로 사용하기 때문에 기존 웹 인프라 사용이 가능하다. |
API는 Application Programming Interface의 줄임말이다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 말한다.
API의 작동 구조
API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명이 된다. API가 생성된 시기와 이유에 따라 API는 네 가지 방식으로 작동한다.
SOAP API | RPC API | Websocket API | REST API |
---|---|---|---|
단순 객체 접근 프로토콜을 사용한다. | 원격 프로시저 호출이다. | JSON 객체를 사용하여 데이터를 전달하는 API 개발이다. | 오늘날 가장 많이 사용되는 유연한 API이다. |
클라이언트와 서버는 XML을 사용하여 메시지를 교환한다. | 클라이언트 앱과 서버간의 양방향 통신을 지원한다. | 클라이언트 앱과 서버간의 양방향 통신을 지원한다. | 클라이언트가 서버에 요청을 데이터로 전송한다. |
클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송한다. | 클라이언트가 서버에 요청을 데이터로 전송한다. | 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있다. | 서버가 클라이언트 입력을 사용하여 내부 함수를 시작하고 출력 데이터를 다시 클라이언트에 반환한다. |
자 드디어 REST API가 나왔다. REST API는 REST 기반으로 서비스 API를 구현한 것이다.
웹 애플리케이션이 제공하는 각각의 데이터를 리소스로 간주하고 각각의 자원에 고유한 URI를 할당함으로써 이를 표현한 API이다.
REST API의 장점
통합 : API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는데 사용된다. 각 기능들을 처음부터 작성할 필요가 없기 때문에 개발에 있어 용이.
혁신 : 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 한다. 따라서 전체 코드를 다시 작성할 필요 없이 API를 변경할 수 있다.
확장 : API는 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유 기회를 제공한다. 예로 지도 API를 사용하면 웹, 모바일 등을 통해 지도 정보 통합이 가능하다.
유지 관리의 용이성 : API는 두 시스템 간의 게이트웨이 역할을 한다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 한다.
REST는 위 정의들을 구현하는 방식에 제약을 두지 않기 때문에 구체적인 가이드라인이 없다. 하지만 RESTful이라는 개념을 통해 그 가이드라인이 제시됩니다. RESTful는 REST를 REST답게 쓰기 위한 방법으로 누군가가 공식적으로 발표한 것이 아니라 여러 개발자들이 비공식적으로 의견을 제시한 것들로 명확한 정의는 없다. 즉 개발자마다 생각하는 RESTful의 내용이 다르다. 하지만 RESTful의 목적은 명확하다. 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것이다.