REST API란?
R~E~S~T~하게 클라이언트와 서버간에 데이터를 주고받는 방식
--- 그럼 REST하지 않은 통신 무엇인가요
=> SOAP API, Chatter REST API, 스트리밍 API 등등
구성
- 자원(RESOURCE) - URL
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
예를들어 영화예매페이지에서 고객이름, 좌석번호, 예매번호, 영화정보 등은 자원(RESOURCE)
이다.
자원은 각각의 URL을 가지고있다. 각각을 URL에서 메소드(행위)를 통해 통신한다. 메소드의 종류에는 GET(조회), POST(생성), PUT(수정), DELETE(삭제)가 있다.
왜 사용하는가
- 프론트엔드와 백엔드가 분리되기 시작함
- JSON형태로 데이터를 제공하는 API를 제공
- View 영역이 포함되지 않는 서버사이드 개발을 진행
특징
- Uniform Interface
편리하고 단순하다. URL로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행할 수 있다.
- Stateless(무상태성)
상태의 정보를 저장하고 관리하지 않는다. 들어오는 요청만 단순히 처리하면 된다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해진다.
- Cacheable
가장 큰 특징중 하나인 HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 사용할 수 있다.
- Self-descriptiveness(자체표현구조)
REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현구조로 되어있다.
- Client - Server 구조
서버는 API를 제공, 클라이언트는 사용자 인증이나 컨텍스트를 직접관리하면서 역할이 구분되기 때문에 개발해야할 내용이 명확해지고 의존성이 줄어들며 생산성있는 개발이 가능하게 된다.
참고
REST가 참.. 생각보다 훨씬 훨씬 훨씬 어렵더라구요. 마치 SMTP가 이메일에서 쓰는 프로토콜이라길래 '아니 뭐 제목이랑 수신자랑 내용 말고 뭐 별거 있겠어?' 싶었는데 MX record고 뭐고 심오한거 엄청 많네 하고 느꼈던 것처럼.. REST한 어플리케이션이라고 말하려면 무조건 HATEOAS를 지켜야 하는데 JSON payload로 request/response하는 요즘 API에선 지키기가 정말 어렵지요. 저는 그냥 HTTP API라고 불러요. REST에 관해선 '그런 REST API로 괜찮은가'라는 슬라이드가 매우 유명합니다.