REST API

REST API

 

REST (Representaion State Transfer)의 약자다

자원을 고유한 이름(URI)으로 식별하고, 해당 자원의 상태(데이터)를 주고받는 아케텍처 스타일

 

Representaion : 자원의 표현으로, 요청 URL로 표현한다

State : 자원의 현재 상태

 

HTTP URL을 통해 자원을 명시한다HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 명시한다

• GET (조회)
• POST (생성)
• PUT (수정)
• DELETE (삭제)

REST API는 웹의 모든 자원에 대해서 고유한 ID(HTTP 요청 URI)를 부여한다

 

 

REST API의 등장배경

 

단순하게 하나의 브라우저만 지원하던 방식에서 멀티플랫폼과 멀티디바이스가 등장했다

그러다 보니 플랫폼에 맞춰서 새로운 애플리케이션을 개발하는 대신, 범용적으로 사용성을 보장하는 새로운 서버 애플리케이션 디자인이 필요해졌기 때문에 등장했따

 

단순하게 하나의 브라우저만 지원하던 시대때는 JSP, ASP, PHP 등을 이용해서 PC 브라우저에 표시할 HTML을 동적으로 생성해서 응답을 보냈다

 

현재 멀티플랫폼, 멀티디바이스 시대에는 XML 또는 JSON과 같은 클라이언트 친화적인 데이터 형식을 제공하는 REST 기반의 개발이 주류가 되었다

 

 

REST의 구성

 

자원의 이름 (Resource)

• 모든 자원에는 고유한 ID가 존재한다
• 자원을 구분하는 ID는 /user/1 (예시)와 같은 HTTP URI다

자원에 대한 행위 (HTTP Method [Verb])

• HTTP 프로토콜의 메소드를 사용해서 지정한다

 

자원의 표현 (Representation of Resource)

• REST에서 하나의 자원에서 JSON, XML 형태로 표현된다.  (JSON은 간결하고 가벼운 데이터 전송에 유용하고, XML은 복잡한 데이터 구조를 표현할 때 유용하다)

 

 

REST 특징

 

 

Uniform(유니폼 인터페이스)

URI로 지정한 리소스에 대한 조작은 통일된 인터페이스를 사용하여 수행된다.

이로 인해 클라이언트와 서버간의 인터페이스가 단순화되고 일관성을 유지할 수 있다

 

Stateless(무상태성)

REST는 무상태성을 가지고 있어 세션정보나 쿠키정보를 별도로 저장하고 관리하지 않는다

이로 인해 서버에 부담을 덜 수 있고, 확장성이 높아진다

 

Cacheable(캐시가능)

HTTP의 캐싱 기능을 활용하여 응답을 저장하고 재사용할 수 있다. 이는 네트워크 지연을 줄이고 성능을 향상시키는데 도움을 준다

 

Self-descriptiveness(자체 표현구조)

REST API 메세지는 간결하고 명확한 자체 표현 구조를 가지고 있어, 문서의 필요성을 줄이고 개발자들이 더 쉽게 이해하고 사용할 수 있다

 

Client-Sever 구조

서버와 클라이언트에서 개발할 내용이 명확하게 구분되어 있고, 서로간의 의존성이 낮다

 

계층형 구조

REST API 서버는 다층 계층으로 구성될 수 있으며, 보안, 로드밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있다

 

 

REST API 디자인 규칙

 

 

URI로 자원의 이름을 표현한다

(URI는 정보의 자원을 표현해야한다. 리소스명은 동사보다 명사를 사용)

// 유효하지 않은 URI. 
// URI에 행위를 나타내는 동사는 적합하지 않다 
GET	/members/delete/1
GET	/deleteMember?id=1
GET	/getMember?id=1
POST	/member/modify

 

// 유효한 URI
DELETE	/member/1
GET	/member/1
PUT	/member/1

 

 

HTTP Method로 자원에 대한 행위를 표현한다

// 회원정보를 조회하는 URI
GET	/member/show/1	(X)
GET	/member/1	(O)

// 회원정보를 삭제하는 URI
GET	/member/delete/1(X)
DELETE	/member/1	(O)

// 회원정보를 수정하는 URI
POST	/member/1	(X)
PUT	/member/1	(O)

// 회원정보를 추가하는 URI
POST	/member	(O)

 

 

URI 설계시 주의 사항

 

• URI 마지막 문자로 슬래시를 포함하지 않는다
• URI에는 밑줄(_)은 사용하지 않는다
• URI에는 소문자를 사용한다
• 파일의 확장자는 URI에 포함하지 않는다 ( .jpg, .png, .txt 등)
• 리소스간의 연관관계가 있을 경우는 아래와 같이 표현한다
  • EX) GET  /member/{memberId}/orders/{orderId}  (/리소스명/리소스ID/관계가 있는 다른 리소스명)
• 자원을 표현할 때 Collection과 Document 를 구분해야한다
  • Collection은 여러 개 리소스, Document 한 개의 리소스
  • EX) GET  /sports/soccer  (축구에 대한 정보를 조회)

 

 

REST API URI 작성예시

요청방식	URL	요청데이터	응답데이터
GET	/members	없음	모든 사용자정보	모든 사용자정보를 추가한다
GET	/members/1	없음	사용자정보	1번 사용자정보를 조회한다
DELETE	/members/1	없음	없음 혹은 사용자정보	1번 사용자정보를 삭제한다
PUT	/members/1	사용자정보	없음 혹은 사용자정보	1번 사용자정보를 수정한다
POST	/members	사용자정보	없음 혹은 사용자정보	새 사용자 정보를 추가한다

 

요청데이터는 요청메세지의 바디부에 포함되어 서버로 전달되는 데이터다

응답데이터는 응답메세지의 바디부에 포함되어 클라이언트로 보내지는 데이터다

요청 URI에 포함된 /member/1의 1은 요청데이터가 아니다

 

 

대표적인 HTTP 응답코드 

 

200	클라이언트의 요청을 성공적으로 수행
201	클라이언트가 리소스의 생성을 요청, 해당 리소스를 성공적으로 생성 (POST 요청을 통한 리소스 생성시 응답코드)
400	클라이언트의 요청이 부적절할 때
401	클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때
403	클라이언트의 요청을 거부할 때
404	클라이언트가 요청한 리소스가 존재하지 않을 때
405	클라이언트가 요청한 요청방식이 지원하지 않을 때
500	클라이언트의 요청을 처리하는 중 서버 오류가 발생했을 때