Rest API

Vorhandenheit ·2021년 10월 14일
0

Web

목록 보기
3/8

Rest API (Representational State Transfer)

HTTP 통신에서 어떤 자원에 대한 CRUD 요청을 Resource와 Method로 표현하여 특정한 형태로 전달하는 방식

Rest

REST 란?
1. HTTP URI을 통해 자원을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 걸 의미

CRUD Operation

Create : 데이터 생성 (POST)
Read : 데이터 조회 (GET)
Update : 데이터 수정 (PUT)
Delete : 데이터 삭제 (DELETE)

1) 구성요소

    1. 자원 : HTTP URI
    1. 자원에 대한 행위 : HTTP Method
    1. 자원에 대한 행위의 내용 : HTTP Message Pay Load

2) 특징

    1. Server - Client(서버-클라이언트 구조)

REST 서버는 API를 제공하고, 제공된 API를 이용해서 비즈니스 로직 처리 및 저장을 책임짐
클라이언트의 경우 사용자 인증이나 Context등을 직접 관리하고 책임 지는 구조로 역할이 나뉘어지고 있음

    1. Stateless(무상태)

사용자나 클라이언트의 Context를 서버 쪽에 유지하지않는다는 의미
상태정보를 저장히지 않으면 API 서버는 들어오는 요청의 메시지로만 처리하면 되며, 세션과 같은 Context 정보를 신경 쓸 필요가 없기 떄문에 구현이 단순해 짐

    1. Cachedable(캐시 처리 가능)

자기 서술형 메세지 덕분에 각각의 요청에 대한 응답은 그 자체로 해석이 가능, 그렇기 떄문에 독립적으로 처리가 가능, 이로인해 Cachinhg이 가능해짐

    1. Layered System(계층화)

서버는 클라이언트가 모르게 API 서버에 여러 계층을 추가하여 유연한 구조로 개발 될 수 있음
클라이언트에서는 REST API서버만 호출하지만 서버는 다중 계층으로 구성될 수 있음

    1. Uniform Interface(인터페이스 일관성)

REST는 HTTP 표준만 따른다면, 어떠한 기술이든 사용이 가능한 인터페이스 스타일
예를 들면, HTTP + JSON으로 REST API를 정의한다면, 안드로이드 플랫폼이건, IOS플랫폼이건 특저언어나 기술에 종속받지않고 HTTP 와 JSON에 사용할 수 있는 모든 플랫폼에 사용 가능한 느슨한 결합 형태의 구조

RESTful API

REST API 설계 가이드에 따라 API를 만들어서 웹 서비스를 제공하는 것

3) 리차드슨 REST 성숙도 모델

A. 레벨 0

  • 웹 메커니즘을 전혀 사용하지 않고 HTTP를 원격 통신을 위한 전송시스템으로 사용함
  • RPC(Remote Procedure Call)형태 resource 구분 없이 설계된 API

주치의와 약속을 예약하는 경우, 먼저 주어진 날짜에 주치의가 예약되지 않은 시간대를 알아내야 한다. 그리고 병원 예약 시스템으로 그러한 정보를 요청하고 병원은 정해진 URI로 서비스 엔드 포인트를 제공하고 내 프로그램은 해당 엔드포인트로 요청 정보를 포함하는 문서를 보낸다.

클라이언트 요청

POST / appointmentService HTTP / 1.1

<openSlotRequest date = "2021-10-04" doctor ="choi"/>

서버에서 응답

HTTP /1.1 200 OK

<openSlotList>
  <slot start = "1400" end = "1450">
    <doctor id = "choi"/>
  </slot>
<slot start = "1600" end = "1650">
  <doctor id = "choi"/>
   </slot>
</openSlotList>

클라이언트 확인후 다시 요청

POST /appointmentService HTTP / 1.1
<appointmentRequest>
  <slot doctor = "choi> start "1400" end= "1450"/>
	<partient id ="smith"/>
</appointmentRequest>

서버 확인후, 응답

HTTP / 1.1 200 OK
<appointment>
	<slot doctor = "choi" start ="1400" end  = "1450"/>
      <patient id = "smith"/>
</appointment>

B. 레벨 1 리소스

  • 모든 요청에 대해 Endpoint간 단일 통신이 아닌, 개별 리소스와 통신하게 됨
  • 해당 동작 또는 기능에 대한 리소스를 URI 형태로 받게되고 이 리소스를 이용하여 요청
  • resource 형태로 구분되어 있으나 action을 HTTP commnad로 CRUD로 표현하지 않은 HTTP API

클라이언트 요청, 레벨 0과는 다르게 의사에 대한 리소스를 가지고 있음

POST / doctors/ choi HTTP/ 1.1
<openSlotRequest date = "2010-01-04">

서버 응답

HTTP / 1.1 200 OK
<openSlotList>
  <slot id = "1234" doctor = "choi" start = "1400" end = "1450" />
    <slot id = "1234" doctor = "choi" start = "1600" end = "1650" />
</openSlotList>

클라이언트 해당 리소스로 요청

POST/ slots/1234 HTTP/ 1.1
<appointmentRequest>
  	<patient id ="choi"/>
</appointmentRequest>

서버 응답

HTTP / 1.1 200 OK

<appointment>
  <slot id = "1234" doctor = "choi" start = "1400" end = "1450" />
  <patient id = "smith"/>
</appointment>

C. 레벨 2 - HTTP 메소드

  • resource 형태로 구분된 URI 와 HTTP command로 CRUD로 표현하나 self-descriptive hypermedia type을 가지지 않는 HTTP API

클라이언트 요청 : 시간대 목록

GET /doctors/choi/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

서버 응답
HTTP/1.1 200 OK

D. 레벨 3 - 하이퍼미디어 컨트롤

  • 하나의 컨텐츠가 텍스트나 이미지, 사운드와 같은 다양한 포맷의 컨텐츠를 링크하는 개념, 관련 컨텐츠를 보기 위해 링크를 따라가는 방식과 유사한 방식으로 동작, 클라이언트가 다른 자원에 대한 링크를 통해 서버와 상호작용
  • 클라이언트에 영향을 미치지않으면서 서버를 변경하는게 가능
  • response payload에 관련된 URI를 포함하는 hypermedia로써 속성을 지님으로 code on demeand 속성을 지원할 수 있는 완전한 REST API

클라이언트 요청

GET/doctors/choi/slots?date=20100104&status=open HTTP/1.1
HOST : royalhope.nhs.uk

서버 응답

HTTP/1.1 200 OK
<openSlotList>
  <slot id= "1234" doctor = "choi" start="1400" end = "1450">
    <link rel = url="/slots/1234?"/>
    </slot>
  <slot id= "5678" doctor = "choi" start="1600" end = "1650">
     <link rel = url="/slots/5678">
    </slot>
</openSlotList>

하이퍼미디어 컨트롤의 요점은 그것들이 다음에 무엇을 할 수 있는지와 그것을 하기 위해 다루어야 할 리소스의 URI를 알려줌

클라이언트 확인후 요청

POST/slots/1234 HTTP/1.1
<appointmentRequest>
  <patient id = "smith"/>
</appointmentRequest>

서버 응답

HTTP /1.1 201 Created
Location: http .... /slots/1234/appointment

<appointment>
  <slot id = "1234" doctor = "choi" start = "1400" end = "1450"/>
    <patient id = "choi"/>
      ...링크
  </appointment>

서버가 클라이언트에 문제를 일으키지않고 URI scheme을 변경할 수 있음

profile
읽고 기록하고 고민하고 사용하고 개발하자!

0개의 댓글