REST? API?

API

API는 프로그램간 의사소통을 위한 인터페이스를 의미합니다. 보통 웹 구조는 클라이언트와 서버간의 통신을 필요로 하며 컴퓨터 간의 통신은 사람간의 통신에서 처럼 문맥을 통한 유추가 불가능하기 때문에 명확한 약속이 필요합니다.

API는 실생활 에서도 예시를 쉽게 찾아볼 수 있습니다. 제가 API를 이해한 예시를 통해 설명해 보도록 할게요.

• 저는 지금 몹시 카페인이 필요합니다. 가까운 곳에 스타벅스로 빨리 가보도록 하죠
• 스타벅스에 들어가 수많은 메뉴중 제가 필요로 하는 아이스 아메리카노 그란데 사이즈를 주문하려 합니다.
• 평소에 저라면 메뉴를 보고 점원분께 아이스(옵션) 아메리카노(원하는 메뉴) 그란데(사이즈)로 주세요라 주문합니다.
• 점원분은 제 요청에 따라 레시피를 따라 커피를 만들어 주십니다.
• 커피가 만들어지는 과정, 에스프레소와 물의 비율 같은 세부사항은 몰라도 저는 원하는 메뉴를 정확히 받아서 만족합니다.

스타벅스의 메뉴판을 통해 저는 아이스 아메리카노를 만드는 방법을 몰라도 제가 원하는 커피를 빠른시간에 주문한대로 받아볼 수 있습니다. API는 바로 스타벅스의 메뉴판과 같은 역할을 합니다.

REST

Representational State Transfer
표현에 의한 상태 전송이라 직역할 수 있을것 같으나 마음에 와닿는 표현은 아닙니다...ㅜ

단어 자체에서 뜻을 유추하기 보단 REST를 규정하는 REST의 특징과 구성을 통해서 확인해 보는게 더 좋을것 같네요!

REST 의 구성

REST는 크게 3가지로 구성됩니다.

• 자원: API를 통해 주고받을 대상입니다. URI가 자원에 해당됩니다.
• 행위: 자원에 대한 행위를 말합니다. HTTP Method로 표현됩니다.
• 표현

URI는 정보의 자원을 표현해야 한다. 자원에 대한 행위는 HTTP Method로 표현한다.

REST 의 특징

• Uniform(유니폼 인터페이스): URI로 지정한 자원에 대한 조작을 '통일'되고 '한정'적인 인터페이스로 수행해야 합니다.
• Stateless(무상태성): 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 따라서 각 요청에서 작업을 처리하기 위한 모든 정보를 포함해야 합니다.
• Cacheable(캐싱 가능성): 자원을 클라이언트 또는 서버측에 캐싱할 수 있어야 합니다. 그리고 REST는 기존의 웹표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 적용 가능합니다.
• self-descriptiveness(자체 표현 구조): REST API 메세지만 보고도 자원과 행위를 이해할 수 있어야 합니다.
• Client-Server 구조(디커플링): 서버와 클라이언트는 서로 간에 완전히 독립적이어야 합니다. 이로 인해 각 포지션에서 개발해야할 내용이 명확해지고 의존성이 줄어들게 됩니다.
• 계층형 구조: 호출과 응답이 서로 다른 계층을 통과합니다. 서버와 클라이언트가 직접적으로 연결되지 않으며 다수의 서로 다른 중개자가 존재합니다. REST API는 엔드 어플리케이션 또는 중개자와 통신하는지 여부를 클라이언트나 서버가 알 수 없도록 설계되어야 합니다.

REST 중심 규칙

• URI는 정보의 자원만을 표현해야 합니다. URI에는 자원에 대한 행위가 들어가면 안됩니다.
• 자원에 대한 행위는 HTTP Method로 표현해야 합니다.
• URI는 자원을 표현하는 데에 집중하고 행위에 대한 정의는 HTTP Method를 통해 합니다.

REST API는 REST한 API를 의미합니다. REST의 특징을 충족하며 REST의 규칙을 따라 API가 구성된다면 RESTful API입니다. 이는 개발자에게 API 구성에 유연성과 자유를 제공합니다. REST API는 정해진 프레임이 없습니다.

REST API의 필요성

• 웹 설계의 우수성에 비해 제대로 활용되지 못하는 점을 보완하고자 탄생하였습니다.
• API 본연의 목적인 소통 비용 감소를 위한 통신의 표준화를 달성하기 위해 필요합니다.
• 기존 웹 아키텍쳐의 장점을 극대화 하며 위의 두가지 이유를 달성하면서도 개발자에게 유연성과 자유를 부여할 수 있습니다.

REST 설계시 주의할 점

• 슬래시 구분자는 계층 관계를 나타내는데 사용합니다

http://starbucks.example.com/coffees/americano
http://starbucks.example.com/teas/peppermint

• URI 마지막 문자로 슬래시를 포함하지 않습니다.

• 하이픈은 URI 가독성을 높이는데 사용합니다.

• 밑줄은 사용하지 않습니다.

• 경로에는 소문자가 적합합니다.

• 파일 확장자는 URI에 포함시키지 않습니다. (Accept 헤더를 사용!)

• 리소스간 관계 표현

  • 슬래시를 기준으로 오른쪽의 리소스는 왼쪽 리소스에 포함되는 관계를 보통 의미합니다.(has)

  • '포함' 관계가 아닌 다른 복합적 관계일 경우의 예 ex 좋아하는

    GET: /users/{userid}/likes/devices

• 컬렉션은 복수로 도큐먼트는 단수로 표현합니다.