[NetWork] REST API

REST API

REST(Representational State Transfer)란?

• 웹 상의 자원을 HTTP URI를 통해 특정하고 HTTP Method를 통해 해당 자원에 대한 작업을 수행하는 방식을 말함
• REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 사용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일임

REST의 구성요소

• 자원(Resource): URI를 통해 자원의 이름을 나타내고 웹 상에서 해당 자원을 찾을 수 있는 위치를 제공

ex: 'https://www.example.com/products'

• 행위(Verb)

HTTP 메소드(GET, POST, PATCH, DELETE 등)

• 표현(Representations)
  • 클라이언트와 서버가 데이터를 주고 받는 형태
  • JSON, XML, TEXT, RSS 등이 있음
  • 주로 JSON이나 XML을 통해 데이터를 주고 받음

[
  {
    "name": "globe",
    "price": 50000,
    "color": "black"
  },
  {
    "name": "shirts",
    "price": 30000,
    "color": "red"
  }
]

위 JSON 객체는 서버가 클라이언트에게 보내는 표현임. 이를 통해 서버는 'products' 자원의 상태를 JSON 형태로 클라이언트에게 전달함

REST의 원칙(특징)

(1) Uniform (유니폼 인터페이스)
모든 자원과 행위가 일관된 방식으로 이루어지는 아키텍처를 말함
ex: 모든 웹 자원은 URI로 표현되고, 해당 자원에 대한 행위는 HTTP 메소드(GET, POST, PUT, DELETE 등)로 일관되게 표현됨 -> 개발자가 API를 쉽게 이해하고 사용할 수 있도록 도와줌


(2) Stateless (무상태성)
REST는 작업을 위한 상태정보를 따로 저장하고 관리하지 않음.
세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됨 -> 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해짐


(3) Cacheable (캐시 가능)
HTTP라는 기존 웹표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 활용이 가능함. 따라서 HTTP가 가진 캐싱 기능이 적용 가능함. Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능함(서버에서 응답과 함께 온 'Last-Modified' 태그나 'ETag' 태그를 받아 자동으로 저장하고, 다음 요청 시 'If-Modified-Since' 또는 'If-None-Match' 헤더를 추가하여 요청을 보냄)


(4) Self-descriptiveness (자체 표현 구조)
REST API 메시지만 보고도 이를 쉽게 이해 할 수 있음


(5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됨


(6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있음
즉, 클라이언트가 직접 연결된 서버로부터만 응답을 받는 것이 아니라, 여러 개의 중간 계층(로드 밸런서, 캐시 서버 등)을 거쳐서 응답을 받을 수 있다는 의미임.
ex: 클라이언트의 요청이 먼저 로드 밸런서에 도착 -> 로드 밸런서는 요청을 처리할 서버를 선택하여 요청을 전달

이런 계층형 구조는 시스템의 확장성과 유연성을 높여줌

REST API

REST의 원칙을 따르는 API를 의미함

REST API의 설계 규칙

1. URI는 대문자보다는 소문자를, 동사보다는 명사를 사용

http://www.example.com/Member/delete/1 (x)
http://www.example.com/member/1 (O)

URI는 자원을 표현하는데 중점을 두어야 하기 때문에 delete와 같은 행위에 대한 표현이 들어가서는 안 됨
그리고 대소문자에 따라 다른 리소스로 인식하게 되기 때문에 URI에 대문자는 가급적 사용하지 않는게 좋음

2. 마지막에 슬래시를 포함하지 않음

http://www.example.com/run/ (x)
http://www.example.com/run (O)

3. 언더바(_) 대신 하이픈(-)을 사용

http://www.example.com/run_member (x)
http://www.example.com/run-member (O)

4. URI에 파일 확장자 포함하지 않음

http://www.example.com/photo.jpg (x)
http://www.example.com/photo (O)

5. 행위를 포함하지 않음

`DELETE` http://www.example.com/delete/post (x)
`DELETE` http://www.example.com/post/:id (O)

행위에 대한 정의는 HTTP METHOD를 통해 하기!

HTTP 응답 상태 코드

잘 설계된 REST API는 리소스에 대한 응답을 잘 주는 것까지 포함되어야 함

상태코드	설명
200	클라이언트의 요청을 정상적으로 수행함
201	클라이언트가 보낸 요청이 처리되어 리소스가 성공적으로 생성됨(POST)
202	요청은 접수했지만 처리가 완료되지 않았음. 응답 헤더의 Location, Retry-After를 참고해 클라이언트를 다시 요청 보내야함
301	클라이언트가 요청한 리소스에 대한 URI가 변경되었음
303	다른 위치로 요청
400	클라이언트의 요청이 부적절할 경우
401	지정한 리소스에 대한 엑세스 권한 없음
403	유저 인증 상태와 관계없이 응답하고 싶지 않은 리스소를 클라이언트가 요청했을 때
404	지정한 리소스를 찾을 수 없음
405	클라이언트가 요청한 리소스에서 사용 불가능한 메소드를 이용했을 경우
500	서버에러
501	요청한 URI의 메소드에 대해 서버가 구현하고 있지 않음
502	게이트웨이 혹은 프록시 역할을 하는 서버가 그 뒷단의 서버로부터 잘못된 응답을 받았음
503	현재 서버에서 서비스를 제공할 수 없음 보통 서버 과부하나 서비스 점검 등의 일시적인 상황

RESTful API이란?

REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful한 API라고 함

예를 들면 어떤 사람이 /api/post라는 URI에 대한 CRUD에 관한 행위를 모두 POST로 처리했다고하면 REST를 사용하긴 했지만 설계 규칙을 제대로 지키지 않음(유니폼 인터페이스 원칙에 어긋남) -> REST API를 사용하긴 했지만 RESTful하지 못하다고 할 수 있음