REST API

Dayeon myeong·2022년 3월 23일

면접

목록 보기

22/35

REST

REST는 HTTP URI를 통해 자원을 명시하고, HTTP 메서드(Get, Post, Put, Delete)로 해당 자원에 대해 삽입, 조회, 갱신, 변경 명령을 적용할 수 있는 소프트웨어 아키텍처

RESTful : REST 원리를 따르는 시스템
REST API : REST 기반으로 서비스 API를 구현한 것

API

Application Programming Interface

응용프로그램이 운영체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 하는 인터페이스

REST 요소 : URI, Method, Message

URI : 리소스, 리소스를 명사형태로 표현
- ex. http://myweb/users
- URI (uniform resource identifier)로 자원을 식별할 수 있는 유일한 주소이다.
Method
- POST : 생성, post만 idempotent하지 않다.
- GET
- PUT
- DELETE
Message : json, xml같은 메시지 포맷으로 메시지를 응답

Idempotent

idempotent란 한 번 요청했을 때와 두 번 이상 요청했을 때 시스템의 상태가 동일한 것을 얘기한다.

f(x) = f(f(x))
- x의 타입과 f(x)의 타입은 같아야 함
- 즉, HTTP 멱등성→ f : HTTP 요청 , x : 시스템의 상태

예를 들어

GET /data?name=dayeon : 단순 조회, idempotent함. GET요청을 한번해도,여러번해도 다 시스템 상태가 동일하다. DB 시스템을 생각해보면 단순히 DB에 있는 것을 조회할 뿐. 항상 DB 시스템 상태는 동일하다.
PUT /data/3?name=dayoen : 수정이나 생성. 특정 리소스 위치를 정확히 지정해서 수정이나 생성해버림. idempotent함. DB 시스템을 생각해보면 항상 DB 시스템 상태는 id가 3번인 row에 대해서 항상 name이 dayeon으로 동일할 것이다.
DETELE : 한번해도, 여러번해도 특정 데이터가 삭제된 시스템의 상태로 동일한다.

POST idempotent하지 않다.

POST /data?name=dayeon : 생성, idempotent 하지 않다. 한번 요청시 DB에 name이 dayeon인 데이터가 생성되고, 두번 요청시 DB에 또 한번 name이 dayeon인 데이터가 생성된다. 요청할 때마다 데이터가 DB에 쌓이면서 DB 시스템의 상태가 달라진다.

REST 특징 : Uniform Interface

HTTP 표준에만 따른다면, 어떠한 기술이라던지 사용이 가능한 인터페이스 스타일

ex. REST API 정의를 HTTP + JSON로 하였다면, C, Java, Python, IOS 플랫폼 등 특정 언어나 기술에 종속 받지 않고, 모든 플랫폼에 사용이 가능.

REST 특징 : Self- descriptive Message

API 메시지만 보고, API를 이해할 수 있는 구조 (Resource,Method를 이용해 무슨 행위를 하는지 직관적으로 이해할 수 있다.)

REST 특징 : Stateless 무상태성

HTTP Session과 같은 컨텍스트 저장소에 상태 정보 저장하지 않아서 요청과 요청 사이에 공유 되는 상태가 없다.

단순히 message같은 것을 통해 데이터를 전달하면 되므로, 구현이 단순해짐

REST 특징 : HATEOAS

Hypermedia As the Engine Of Application State

Application의 상태(State)는 Hyperlink를 통해 전이되어야함.
서버는 현재 이용 가능한 다른 작업에 대한 하이퍼링크를 포함하여 응답해야함.
특정 API를 요청한 후 다음 단계로 할 수 있는 작업을 알려주는 것이며, 다음 단계의 작업을 위한 리소스의 URI를 동적으로 알려준다. 따라서, 클라이언트는 동적으로 생성된 URI를 사용함으로써 URI가 변경되어도 코드를 수정하지 않아도 되는 편리함이 존재한다.

REST 장단점

[ 장점 ]
API만 봐도 쉽게 이해할 수 있고 사용이 쉽다 : REST API 의 URI, 메서드, 메시지를 읽는 것만으로도 메시지가 의도하는 바를 파악할 수 있어서 굳이 기능이 무엇인지 알아야할 필요가 없다. 또한 서버에서 진행된 내용들을 클라이언트가 알지않아도 되서 해당 URI와 원하는 메소드 자체만 독립적으로 이해하기만 하면 됨

[ 단점 ]
표준의 부재 : 표준이 존재하지 않아서 관리의 어려움과 공식화된 API 디자인 가이드가 존재하지 않는다.