일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- 정보처리기사
- doitandroid
- 인프런
- 코틀린
- 오블완
- CS
- Til
- 기술면접
- 정처기
- 혼공단
- 안드로이드스튜디오
- 프로그래머스
- select
- 혼공챌린지
- join
- 티스토리챌린지
- 혼공파
- 카카오코테
- 스터디
- 안드로이드
- 코테
- java
- groupby
- Android
- 자바
- MySQL
- SQL
- 자료구조
- 알고리즘
- Kotlin
- Today
- Total
Welcome! Everything is fine.
#09. RESTful API 정리 본문
이번주 질문 중 하나인 RESTful API. 과연 RESTful API란 무엇일까? RESTful API를 검색해보면 가장 상단에 있는 AWS 사이트에서 다음과 같이 설명하고 있다. 하지만 너무 간단한 설명이다.
RESTful API는 두 컴퓨터 시스템이 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스입니다.
스크롤을 좀 더 내려 들어간 IBM 사이트에서는 다음과 같이 설명하고 있다. 그러니까 REST가 뭔지 알려줘야지...
REST API는 REST(REpresentational State Transfer) 아키텍처 스타일의 디자인 원칙을 준수하는 API입니다. 이러한 이유로 REST API를 RESTful API라고도 합니다.
REST의 뜻도 모르고, 심지어는 API의 개념도 머릿속에 남아있지 않은 상태에서 하나씩 검색해보며 차근차근 공부해보았다.
REST란?
REpresentational State Transfer의 약자로, 자원을 이름(표현)으로 구분하여 자원의 상태 정보를 전달하는 것을 의미한다.
REST의 구성요소는 다음과 같이 자원, 행위, 표현으로 이루어진다.
자원(Resource)
- 자원 - URI로 구현함.
- 슬래시(/) 구분자를 통해 자원 간의 계층 관계를 나타냄. (ex. dramas/goodplace/actors)
- URI 마지막에는 슬래시(/) 구분자를 포함하지 않음.
- 언더바(_) 대신 하이픈(-)을 사용함.
- URI는 동사가 아닌 명사를, 대문자가 아닌 소문자를 사용함.
- 파일 확장자는 URI에 포함하지 않음.
행위(Verb)
- 행위(or 상태) - HTTP METHOD로 구현함.
- 아래와 같이 HTTP METHOD를 이용해 2개의 URI(/dramas, /dramas/goodplace )만 가지고도 CRUD API를 만들 수 있음.
- GET : 조회 (ex. GET/dramas)
- POST : 생성 (ex. POST/dramas)
- DELETE : 삭제 (ex. DELETE /dramas/goodplace)
- PUT : 업데이트(빈 정보는 null) (ex. PUT/dramas/goodplace)
- PATCH : 업데이트(빈 정보는 기존 데이터) (ex. PATCH/dramas/goodplace)
표현(Representations)
- 리소스의 응답 타입 - 요청 헤더로 나타냄.
- Accept 헤더를 사용해 응답 타입을 지정함.
RESTful API의 가장 큰 특징은 요청 메시지만 보고도 무엇을 원하는지 파악할 수 있다는 것이다!
RESTful API란?
RESTful API란 REST 아키텍처 스타일로 요청과 응답을 하는 API이다. 즉 'RESTful 하다'는 것은 REST 아키텍처의 스타일을 모두 준수했을 경우를 말하고, REST API를 제공하는 웹 서비스를 'RESTful 하다'고 말할 수 있다. 다음과 같이 REST API에서 규정하고 있거나 규정하고 있지 않은 것들을 보고 중요한 항목을 다시 한 번 되새겨보자.
REST API에서 규정하고 있는 것
- 리소스를 식별할 때는 URI를 통해 식별한다.
- 어떤 행위를 할 때는 HTTP의 고유한 METHOD를 이용한다.
- 결과를 알려줄 때는 응답코드를 사용해 알려준다.
REST API에서 규정하고 있지 않은 것
- 클라이언트와 서버가 어떤 데이터 타입으로 통신할 것인지 - JSON, XML 등
RESTful API의 설계원칙
Uniform Interface(인터페이스 일관성)
나머지 원칙들은 인터넷을 사용하면 자연스럽게 그 원칙이 지켜지기 때문에 1번을 지키기 위해 더 노력해야 한다. Uniform Interface는 표준 HTTP METHOD를 사용하는 것, 리소스 기반 URL 패턴을 따르는 것, 자기 서술적인 메세지(HTTP Header에 타입을 명시하는 것을 의)를 보내는 것을 포함한다.
Stateless(무상태성)
REST는 상태 정보를 따로 저장하거나 관리하지 않는다. 클라이언트와 서버의 통신에는 상태가 없어야 하며, 모든 요청은 필요한 모든 정보를 담고 있어야 한다. 필요한 모든 정보를 담고 있으므로 가시성이 높아지고, 상태를 저장할 필요가 없으므로 서비스의 자유도는 높아지고 구현이 단순해진다.
Cacheable(캐시 가능)
모든 서버 응답은 캐시 가능한지 그렇지 않은지 알 수 있어야 한다. REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능을 적용할 수 있다.
Client-Server(서버-클라이언트 구조)
Layered System(계층형 구조)
'CS 스터디' 카테고리의 다른 글
#11. Stack과 Queue의 차이 (0) | 2024.02.18 |
---|---|
#10. 스케줄러의 종류 (0) | 2024.02.13 |
#08. TCP와 UDP의 특징 및 차이 (1) | 2024.02.07 |
#07. OSI 7계층(OSI 7 Layer) 개념 / 각 계층별 특징 (0) | 2024.02.05 |
#06. 절차지향 vs 객체지향 (0) | 2024.01.30 |