Taesun Lee

Taesun Lee

I am currently working with Cloud.

REST API 정리

REST API

모든 http 서비스 호출을 GET, POST로 할 수 있지만, 수행하려는 작업이 명확하게 드러나지 않는다. 이를 해결하기 위해 REST API 규격을 이용할 수 있다. HTTP Method를 통해 CRUD의 동사(행위)를 나타낼 수 있고, URL을 통해, 통제하려고 하는 작업의 대상을 나타낼 수 있다.

정의

  • Representational State Transfer의 약자
  • 웹서비스 작성을 위해 사용되는 규약을 정의하는 software architectural style
  • REST architectural style을 따라 개발한 웹서비스들을 RESTful 웹서비스라고 부른다.

유래

2000년도 Roy Fielding이 그의 박사 논문에서 정의

Architectural Constraint (아키텍처 제약 조건)

Client-server architecture

  • 서버-클라이언트 모델로 구축
  • 서버와 클라이언트 각각의 역할이 분리 되기 때문에, 각각의 역할이 명확하고 서로간의 의존성이 줄어든다.

Stateless

  • 각 요청간의 클라이언트 컨텍스트가 서버에 저장되면 안된다.
  • 클라이언트가 컨텍스트를 유지하고 관리한다. ex) 사용자 인증 정보(Token), 컨텍스트(세션, 로그인 정보)를 직접 관리

Cache가 사용 가능하다

  • HTTP의 캐싱 기능을 사용 가능 ex) Last-Modified tag, E-Tag…

JSON

  • 데이터 포멧으로 JSON을 사용한다.
  • 호환성이 좋다.

기타

  • 쉽게 구축, 확장 가능하다
  • 웹에 최적화 되어있다.

RESTful API 구조

URI와 HTTP 프로토콜을 기반으로 한다.

  • URI: 정보의 자원을 나타낸다.
  • HTTP Method(GET, POST, PUT, DELETE): 자원에 대한 Verb(행위)를 나타낸다.

예시 1 - Collection, Document

예를 들어 users (collection)에 대한 REST API를 아래와 같이 예시를 들 수 있다.

1. GET Method, URI: /users/1
2. DELETE Method, URI: /users/2
3. PUT Method, URI: /users/3
4. GET Method, URI: /users

URI 에서 첫번째 /users의 경우 user의 집합을 나타내며 Collection이라고 부른다. 그리고 두번째 /1, /2, /3의 경우 Collection 내의 특정 자원을 나타내며 Document라고 불리며, ID와 같은 Identifier를 사용한다.

최종적으로 HTTP Method와 URI가 합쳐진 의미는 아래와 같다.

  • 1의 경우 users의 id 1을 가지는 resource를 조회
  • 2의 경우 users의 id 2를 가지는 resource를 삭제
  • 3의 경우 users의 id 3을 가지는 resource를 수정
  • 4의 경우 users collection 전체의 정보를 조회

예시 2 - Sub-Collection

예시 1의 경우에 더불어, 다중 계층을 표현 할 수 있다.

1. GET Method, URI: /schools/3/users/1
2. DELETE Method, URI: /schools/3/users/2
3. PUT Method, URI: /schools/3/users/3
4. GET Method, URI: /schools/3/users

위의 예시에서는, 예시 1의 URI 앞에 ‘/schools/3’이 추가 되었다. 해당 URI들은 ID 3을 가지는 school Document 하위에 존재하는 users의 자원들을 의미한다.

기타 개념

SOAP

  • Simple Object Access Protocal의 약자
  • HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜
  • 웹서비스 내의 모든 데이터는 XML로 표현된다.
  • 보통 원격 프로시져 호출(Remote Procedure Call:RPC)패턴을 사용
    • 클라이언트에서 서버로 메세지를 요청하고, 서버는 메시지를 즉시 응답한다.
  • XML을 기반으로 헤더와 바디를 조합하는 디자인 패턴으로 설계
  • SOA(Service Oriented Architecture)를 실현하기 위한 기술
  • REST 보다 복잡하다.
  • 보안이 요구 되는 경우 선호
  • 더 많은 리소스와 대역폭 필요
  • 캐시 사용 불가

ROA(Resource Oriented Architecture)

  • REST가 기반으로 하는 아키택쳐

Source

  • https://en.wikipedia.org/wiki/Representational_state_transfer
  • https://mygumi.tistory.com/55
  • https://ssup2.github.io/theory_analysis/REST_API/
  • https://meetup.toast.com/posts/92
  • http://blog.wishket.com/soap-api-vs-rest-api-%EB%91%90-%EB%B0%A9%EC%8B%9D%EC%9D%98-%EA%B0%80%EC%9E%A5-%ED%81%B0-%EC%B0%A8%EC%9D%B4%EC%A0%90%EC%9D%80/
  • https://ko.wikipedia.org/wiki/SOAP

Leave a comment

You may also enjoy