REST API -Web API

1. REST

• Stateless(무상태성)
• Cache
• Self-descriptiveness(자체 표현 구조)
• Client-server구조
• Layered System(계층형 구조)
• Uniform Interface

Stateless(무상태성)

작업을 위한 상태 정보를 따로 저장하고 관리하지 않는다. (세션 정보나 쿠키 정보를 가지고 있지 않기 때문에 들어오는 요청만 처리하면 된다.

• 서비스의 자유도가 높아지고 불필요한 정보는 관리하지 않아 구현이 단순해진다.

Cache

HTTP를 사용하기에 HTTP가 가진 캐싱 기능이 적용 가능하다. Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능

Self-descriptiveness(자체 표현 구조)

REST API 메시지만 보고도 쉽게 이해 가능한 자체 표현 구조로 되어있다.

Client-server구조

REST서버(API 제공)와 클라이언트(사용자 인증이나 컨텍스트)의 구조가 분리되므로 개발해야 할 내용이 명확해지고 서로 간 의존성이 줄어든다.

Layered System(계층형 구조)

다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.

Uniform Interface

Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일

 

• 애플리케이션의 상태는 하이퍼 링크(Hyperlink)를 이용해 전이돼야 한다. (HATEOAS)

※HATEOAS

HATEOAS

응답 결과에 보통 JSON 메시지를 사용하게 되는데, 이 JSON메시지가 어디에 전달되는지 그리고 JSON메시지를 구성하는 것이 어떤 의미를 표현해야만 메시지 스스로 설명할 수 있다고 말할 수 있는데, 그게 쉽지 않다.

 

예를 들어) 웹 게시판을 사용할 때, 리스트 화면에서 상세보기나 글쓰기로 이동할 수 있는 링크가 있는데, 상세보기에서는 글 수정이나 글 삭제로 갈 수 있는 링크가 있다.

이렇게 웹 페이지를 보면, 웹 페이지 자체에 관련된 링크가 있는 것을 알 수 있는데 이를 HATEOAS라고 말한다.

---

2. REST API

위에서 설명한 REST 형식을 지키는 API를 가리키는 말이다.

REST API란 핵심 콘텐츠 및 기능을 외부 사이트에서 활용할 수 있도록 제공되는 인터페이스이다.

 

예를 들어, 네이버에서 블로그에 글을 저장하거나, 글 목록을 읽어갈 수 있도록 외부에 기능을 제공하거나 우체국에서 우편번호를 조회할 수 있는 기능을 제거하거나, 구글에서 구글 지도를 사용할 수 있도록 제공하는 것들을 말한다.

출처: https://www.edwith.org/viewer/image?src=https%3A%2F%2Fcphinf.pstatic.net%2Fmooc%2F20180206_20%2F1517901229093n4XI7_PNG%2F001.png

---

3. Web API

1. URI는 정보의 자원을 표현해야 한다.

• GET /members
  : 멤버의 모든 정보를 달라는 요청
• GET /members/delete/1
  : GET은 정보를 요청할 때 사용하는데, 동사로 삭제를 표현하면 안 된다.
• DELETE /members/1
  :DELETE를 이용하여 삭제를 표현해야 한다.

URI는 자원을 표현하는데 중점을 두어야지 행위에 대한 표현이 들어가면 안 된다.

2. 자원에 대한 행위는 HTTP메소드(GET, POST, PUT, DELETE)로 표현한다.

※HTTP Method

• GET: 서버 자원을 가져오고자 할 때 사용, 본문(body)에 데이터를 넣지 않고, 쿼리 스트링을 사용한다.
• POST: 서버에 자원을 새로 등록하고자 할 때 사용, 요청의 본문에 새로 등록할 데이터를 넣어 보낸다.
• PUT: 서버의 자원을 요청에 들어 있는 자원으로 치환하고자 할 때 사용한다.
• DELETE: 서버의 자원을 삭제하고자 할 때 사용한다.

 

• GET /members/1                   (o)
• GET /members/add                (x)
• POST /members                    (o)
• GET /members/update/1         (x)
• PUT /members/1                   (o)
• GET /members/del/1              (x)
• DELETE /members/1               (o)

3. URI설계 시 주의

• URI 마지막 문자로 슬래시 구분자(/)를 포함하지 않습니다.
• 하이픈(-)은 URI가독성을 높일 때 사용합니다.
• 언더바(_)는 사용하지 않습니다.
• URI경로는 소문자만 사용합니다.
• RFC 3986(URI 문법 형식)은 URI스키마와 호스트를 제외하고는 대소문자를 구별합니다.
• 파일 확장자는 URI에 포함하지 않습니다.
• Accept Header를 사용합니다.

4. HTTP 응답 상태 코드

잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 한다. 정확한 응답의 상태 코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이다. 

출처: https://meetup.toast.com/posts/92

 

 

출처 & 참고

• meetup.toast.com/posts/92
• www.edwith.org/boostcourse-web/lecture/16740/