SUNKYUN.COM

SQL/SERVER

SQL/SERVER MSSQL WINDOW SERVER

RESTful API 이해하기

최고관리자
2018.02.26 10:27 3,392 0

본문

RESTful 개념 이해하기

백엔드 개발자라면 REST api라는 용어가 익숙할 것이라고 생각한다. 물론 나도 REST api에 대한 개념을 어렴풋이 갖고 있긴 하지만 그것이 뭐냐고 물으면 정확하게 답변하기가 어렵다. 개념이 제대로 잡히지 않았기 때문이라고 보는데..

일반적은 웹어플리케이션 흐름은 MVC(Model/View Controller내 로직처리에 의한 Model 및 View 변경) 패턴이 일반 적이다. 즉 View의 개념까지를 포함하는 것이 웹의 기본.


23484F4058E3A94B0AC9AB


REST api는 View를 제외한 클라이언트 요청으로 서버내 비즈니스로직을 처리하는 api 정도로 가볍게 이해할 수 있다.

REST(Representational State Transfer)의 약자로 특정 요청에 따른 표현 상태 전이를 표현한다는 의미일까. 위키백과의 설명을 빌리자면 네트워크 아키텍처 원리의 모음으로, 네트워크 아키텍처 원리란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP 위에서 SOAP이나 쿠키를 통한 세션 트래킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다.

브라우저와 같은 웹클라이언트는 URL link와 같은 resource identifer를 통해 resource에 대해 어떤 요청을 하고 그 결과를 받게 된다. 이러한 요청 결과는 브라우저 화면에 새로운 내용이 디스플레이 되는 등의 방식으로 표현된다. 즉, 이 과정을 통해 브라우저 표현상태(Representational State)의 변경(Transfer)을 유발하게 된다. REST는 이러한 특성을 표현한 용어이다. resource는 웹이 제공하는 모든 정보 및 데이터를 의미하며, resource identifier는 resource에 대한 링크이다.

REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다.

REST 아키텍처를 만든 로이필딩은 웹(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.

REST 아키텍처에 적용되는 6가지 제한 조건 (제한조건 준수한다면, 개별 컴포넌트 자유로운 구현 가능)
- 클라이언트/서버 구조(Client-Servcer) : REST 서버는 API 제공. 클라이언트와 서버에서 개발해야할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.
- 무상태(Stateless) : 각 요청 간 클라이언트의 콘텐스트가 서버에 저장되어서는 안된다.
- 캐시처리가능(Cacheable)
- 계층화(Layered System) : REST서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
- 유니폼 인터페이스(Uniform Interface) 
- 자체 표현 구조(Self-descriptiveness) : REST API 메시지만 보고도 이를 쉽게 이해할 수 있는 자체 표현구조로 되었다.

REST의 주요한 목표
- 구성 요소 상호작용의 규모 확장성
- 인터페이스의 범용성
- 구성 요소의 독립적인 배포
- 중간적 구성요소를 이용해 응답 지연 감소, 보안을 강화, 레거시 시스템을 인캡슐레이션.

REST API uri 설계 규칙
- URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용)
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현
     POST : POST를 통해 해당 URI를 요청하면 리소스를 생성.
     GET : GET을 통해 해당 리소스를 조회. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보 로드
     PUT : PUT을 통해 해당 리소스를 수정
     DELETE : DELETE를 통해 해당 리소스를 삭제


웹서비스 백엔드개발시, 흔하게 접하는 API 개발 방식이나 정확한 개념을 잡지 못하고 있었던 것 같다. 제일 무서운것이 대충대충 알고서 상용 서비스에 적용하는 것이 아닐까 싶다. 진정 프로페셔널한 개발자로 나아가고 싶다면 개발 이전 내가 활용하고 있는 개발 방식, 기술에 대한 정확히 이해하고 쓰도록 하자.


REST API JSON 스타일 가이드
https://google.github.io/styleguide/jsoncstyleguide.xml


출처: http://12bme.tistory.com/25 [goorm>=5; 길은 가면, 뒤에 있다]






1) REST란?

HTTP URI를 통해 Resource를 명시하고, HTTP Method(Post, Get, Put, Delete)를 통해 해당 Resource에 대한 CRUD Operation을 적용한다. 즉, REST는 ROA(Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.


HTTP Method와 CRUD Operation은 일반적으로 아래 표와 같이 맵핑된다.
Screen-shot-2013-09-23-at-%25EC%2598%25A4%25ED%259B%2584-11.52.23.png

2) SOAP와 비교


[일반적인 웹서비스]
rest001.jpg

[REST] URL로 요청
rest002.jpg


3) REST의 장점

- OPENAPI를 제공하기 쉽다.
- 멀티플랫폼 지원 및 연동이 용이하다.
- 원하는 타입으로 데이터를 주고받을수 있따. (XML, JSON, RSS )
- 기존 웹 인프라를(HTTP)를 그대로 사용가능하다 ( 방화벽, 장비 요건 불필요 )
- 사용하기 쉽다
- 세션을 사용하지 않는다. 각각의 요청에 독립적.

4) REST의 단점

- 표준이 없어서 관리가 어렵다.
- 사용할 수 있는 메소드가 4가지 밖에 없다.
- 분산환경에는 부적합하다.
- HTTP통신 모델에 대해서만 지원한다.

5) REST의 특징

- 클라이언트/서버 구조 : 일관적으로 독립되어야 한다.
- 무상태(Stateless) : 각요청 간 클라이언트의 Context는 서버에 저장되어서는 안 된다.
- 캐시가능(Cacheable) : WWW에서와 같이 클라이언트는 응답을 Caching 할 수 있어야 한다.
- 계층화(Layered System) : 클라이언트는 보통 대상 서버에 직접 연결 또는 중간 서버를 통     해 연결되는지 모른다.
- Code on demand(option) : 자바 애플릿/ 자바스크립의 제공으로 서버가 클라이언트가 실행   시킬 수 있는 로직을   전송하여, 기능을 확장 할수 있다.
- 인터페이스 일관성 : 아키텍처를 단순화하고, 작은 단위로 분리하여, 클라이언트-서버 파트    별로 독립적으로 개     선 될 수 있도록 한다.
- 자체 표현구조(Self-Descriptiveness) : API 메시지만 보고도 어떤 API인지를 이해 할수 있는 자체 표현 구조    를 가진다.

6) ROA란?

웹의 모든 리소스를 URI로 표현하고 구조적이고 유기적으로 연결하여 비 상태 지향적인 방법으로 정해진 method만을 사용하여 리소스를 사용하는 아키텍처
이는 4가지의 고유한 속성과 연관되어 진다. ( REST는 이 속성들을 지향한다 ) 

  - Addressablilty
  - Connectedness
  - Statelessness
  - Homogeneous Interface

+ Addressablilty (주소로 표현 가능함) 
- 제공하는 모든 정보를 URI로 표시할 수 있어야 한다.
- 직접 URI로 접근할 수 없고 HyperLink를 따라서만 해당 리소스에 접근할 수 있다면 이는 RESTful하지 않은 웹서비스이다.
 

+ Connectedness (연결됨) 
- 일반 웹 페이지처럼 하나의 리소스들은 서로 주변의 연관 리소스들과 연결되어 표현(Presentation)되어야 한다.
 - 예를 들면,
<user>
  <name>HJ</name>
</user> 는 연결되지 않은 독립적인 리소스이다.
<user>
  <name>HJ</name>
  <address>HJ/seoul/</address>
  <phone>HJ/010</phone>
</user> 는 관련 리소스(address, phone)가 잘 연결된 리소스의 표현이다.

+ Statelessness (상태 없음) 
- 현재 클라이언트의 상태를 절대로 서버에서 관리하지 않아야 한다.
- 모든 요청은 일회성의 성격을 가지며 이전의 요청에 영향을 받지 말아야 한다.
- 다시 또 코리아닷컴의 예를 들면 메일을 확인하기 위해 꼭 '..코리아닷컴../mailView.crd'에 접근하여 해당 세션을 유지한 상태에서 메일 리소스에 접근해야 한다. 이것이 바로 Statelessness가 없는 예이다.
 - 세션을 유지 하지 않기 때문에 서버 로드 발란싱이 매우 유리하다.
 - URI에 현재 state를 표현할 수 있어야 한다. (권장사항)

+ Homogeneous Interface (동일한 인터페이스)
 - HTTP에서 제공하는 기본적인 4가지의 method와 추가적인 2가지의 method를 이용해서 리소스의 모든 동작을 정의한다.
 - 리소스 조회 : GET
 - 새로운 리소스 생성 : PUT, POST (새로운 리소스의 URI를 생성하는 주체가 서버이면 POST를 사용)
 - 존재하는 리소스 변경 : PUT
 - 존재하는 리소스 삭제 : DELETE
 - 존재하는 리소스 메타데이터 보기 : HEAD
 - 존재하는 리소스의 지원 method 체크 : OPTION
 - 대부분의 리소스 조작은 위의 method를 이용하여 대부분 처리 가능하다. 만일 이것들로만 절대로 불가능한 액션이 필요할 경우에는 POST를 이용하여 추가 액션을 정의할 수 있다. (되도록 지양하자)


*  supplement

  • SOAP : HTTP, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜

* Reference

댓글목록 0

등록된 댓글이 없습니다.