[ 백엔드 면접 준비 ] REST & REST API & RESTfull API 란??
∇ 백엔드 면접 준비 : REST & REST API & RESTful API 란??
목 차
1. REST.
2. REST API.
3. RESTfull API.
Ⅰ. REST.
Ⅰ - ⅰ REST 정의.
REST( Representational State Transfer ) 는 월드 와이드 웹 같은
분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍쳐의 한 형식입니다.
1. REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에
웹의 장점을 최대한 활용할 수 있는 아키텍쳐 스타일입니다.
2. REST는 네트워크 상에서 Client(프론트) - Server(백) 사이의 통신 방식 중 하나입니다.
◎ 자원을 이름(자원의 표현) 으로 구분하여, 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미합니다.
=== 자원(resource)의 표현(representaion)에 의한 상태 전달.
1. 자원(resource)의 표현(representation)
● 자원 : 해당 소프트웨어가 관리하는 모든 것
ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등
● 자원의 표현 : 그 자원을 표현하기 위한 이름
ex) DB의 학생 정보가 자원일 때, 'students'를 자원의 표현
2. 상태(정보) 전달
● 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달합니다.
● JSON 혹은 XML을 데이터를 주고 받는 것이 일반적.
Ⅰ - ⅱ REST 구체적인 개념.
HTTP URI( Uniform Resource Identifier) 를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미합니다.
● 즉, REST는 자원 기반의 구조(ROA :: Resource Oriented Architecture) 설계의 중심에 Resource가 있고
HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미합니다.
● 웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여합니다.
● CRUD Operation
- Create : 생성 ( POST)
- Read : 조회 (GET)
- Update : 수정(PUT)
- Delete : 삭제(DELETE)
- HEAD : header 정보 조회(HEAD)
Ⅰ - ⅲ REST의 장단점.
∇ 장점.
● HTTP 프로토콜의 인프라를 그래도 사용하므로
REST API 사용을 위한 별도의 인프라를 구축할 필요가 없습니다.
● HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다.
● HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.
● Hypermedia API의 기본을 충실히 지키면서 범용성을 보장합니다.
● REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악 가능합니다.
● 여러가지 서비스 디자인에서 생길 수 있는 문제를 최소화합니다.
● 서버와 클라이언트의 역할을 명확하게 분리시킵니다.
∇ 단점.
● 표준이 존재하지 않습니다.
● HTTP Method 형태가 제한적입니다.
● 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL 보다 Header 값이 더 복잡.
Ⅰ - ⅳ REST가 필요한 이유.
● 애플리케이션 분리 및 통합.
● 다양한 클라이언트의 등장.
- 최근의 서버 프로그램은 다양한 브라우저와 안드로이드*아이폰과 같은 디바이스에서도 통신 가능해야함.
- 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍쳐를 구축하고 활용하기 위해 REST가 필요해짐.
Ⅰ - ⅳ REST 구성 요소.
◎자원(Resource) : URI
● 모든 자원에 고유한 ID가 존재하고, 이 자원은 '서버/DB'에 존재합니다.
● 자원을 구별하는 ID는 '/groups/:group_id' 와 같은 HTTP URI입니다.
● 클라이언트(프론트)는 UIR를 이용해서 필요한 자원을 지정하고,
해당 자원의 상태(정보)에 대한 조작을 서버단에 요청합니다.
◎행위(Verb) : HTTP Method
● HTTP 프로토콜의 Method를 사용합니다.
● HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공합니다.
◎표현(Representation of Resource)
● '클라이언트'가 자원의 상태(정보)에 대한 조작을 요청하면
'서버'는 이에 적절한 응답(Representation)을 보냅니다.
● REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 표현 가능.
● JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적입니다..(현재 웹은 거의 JSON)
Ⅰ - ⅳ REST 특징 정리.
◎ Client(프론트) - Server(백) [클라이언트-서버 구조]
● 자원이 보내주는 쪽이 Server(백), 자원을 요청하는 쪽이 Client(프론트)가 됩니다.
○ REST Server : API를 제공하고 비즈니스 로직 처리 및 저장을 책임집니다.
○ Client : 사용자 인증이나 context(세션,로그인 정보) 등을 직접 관리하고 책임집니다.
● 클라이언트(프론트)-서버(백엔드) 간의 의존성이 줄어들게 됩니다.
◎ Stateless(무상태성)
● HTTP 프로토콜은 Stateless Protocol이므로, REST 역시 무상태성을 가집니다.
● Client의 context를 Server에 저장하지 않습니다.
○ 세션과 쿠키와 같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해집니다.
● Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리합니다.
○ 각 API 서버는 Client의 요청만을 단순 처리합니다.
○ 즉, 이전 요청이 다음 요청의 처리에 연관되어선느 안됩니다.
○ 물론 이전 요청이 DB를 수정하여, DB에 의해 바뀌는 것은 허용합니다.
○ Server의 처리 방식에 일관성을 부여하고 부담이 줄어들며, 서비스의 자유도가 높아집니다.
◎ Cacheable(캐시 처리 가능)
● 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용 가능.
○ 즉, HTTP가 가진 가장 강력한 특징 중 하나인 캐싱 기능을 적용 가능합니다.
○ HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능.
● 대량의 요청을 효율적으로 처리하기 위해서 캐시가 요구됩니다.
● 캐시 사용을 통해 응답시간이 빨라지고 REST Server 트랜잭션이 발생하지 않기 때문에
전체 응답시간, 성능, 서버의 자원 이용률을 향상시킬 수 있습니다.
◎ Layered System ( 계층화 )
● REST Server는 다중 계층으로 구성될 수 있습니다.
○ API Server는 순수 비즈니스 로직을 수행하고,
그 앞단에 보안/로드밸런싱/암호화/사용자 인증 등을 추가하여 구조상의 유연성을 줄 수 있습니다.
○ 또한 로드밸런싱/공유 캐시 등을 통해 확장성과 보안성을 향상시킬 수 있습니다.
● Client는 REST API Server만 호출합니다.
● PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용 가능합니다.
◎ 자체 표현 구조. (Self - descriptiveness)
● JSON을 이용한 메시지 포맷을 이용하여, 직관적으로 이해할 수 있고
REST API 메시지만으로 그 요청이 어떤 행위를 하는지 알 수 있습니다.
◎ Code-On-Demand(optional)
● Server로부터 스크립트를 받아서 Client에서 실행합니다.
● 반드시 충족할 필요는 없습니다.
◎ Uniform Interface(인터페이스 일관성)
● URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행합니다.
● HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능합니다.
○ 즉, 특정 언어나 기술에 종속되지 않습니다.
Ⅰ - ⅴ 중심 규칙.
∇ REST에서 가장 중요하며, 기본적인 규칙은 아래 두가지 !
● URI는 정보의 자원을 표현해야 합니다.
● 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등) 으로 표현합니다.
◎ 세부 규칙.
1. 슬래시 구분자 ( / )는 계층 관계를 나타내는데 사용한다.
2. URI 마지막 문자로 슬래시 ( / )를 포함하지 않는다.
- 즉 URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것
- 역으로 리소스가 다르면 URI도 달라져야 한다.
3. 하이픈 ( - )은 URI 가독성을 높이는데 사용한다.
4. 밑줄 ( _ )은 URI에 사용하지 않는다.
5. URI 경로에는 소문자가 적합하다.
- URI 경로에 대문자 사용은 피하도록 한다.
6. 파일확장자는 URI에 포함하지 않는다.
- REST API 에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
- 대신 Accept Header 를 사용한다.
- ex) GET: http://restapi.exam.com/orders/2/Accept: image/jpg
7. 리소스 간에 연관 관계가 있는 경우
- /리소스명/리소스ID/관계가 있는 다른 리소스 명
- ex) GET: /users/2/orders (일반적으로 소유의 관계를 표현할 때 사용)
Ⅰ - ⅵ . 설계 목표.
- REST의 핵심 설계 목표.
1. 컴포넌트들간의 유연한 (쉽게 확장 가능한) 상호 연동성 확보.
● 상호 연동성 : 서로 상이한 컴포넌트들을 쉽게 연결할 수 있는 성질.
상호연동성은 두 개 이상의 컴포넌트들을 결합함으로써,
작업을 더 효율적으로 수행하도록 하는데 목적.
● 즉, REST는 HTTP와 URI 기반인데, HTTP와 URI 모두 표쥰이며
직관적이고 사용이 간단하며 어디에서든 동일하게 작동하는 것을 보장합니다.
2. 범용 인터페이스.
● 상호연동성과 비슷한 개념으로, REST 모델을 위한 HTTP와 URI는 표쥰으로
어디서든지 사용가능한 범용 인터페이스를 제공합니다.
● 개발자는 비즈니스 로직만 고민하면 됩니다.
3. 각 컴포넌트들의 독립적인 배포.
● 각 컴포넌트들과의 독립적인 배포의 의미
:: 다른 컴포넌트들과 독립적으로 개발을 할 수 있다는 것.
● 규격에 맞추어 개발이 되었다면, 다른 컴포넌트가 추가된다 해도 연동에 걱정 X
4. 지연 감소, 보안강화, 레거시 시스템을 "인캡슐레이션" 하는 중간-컴포넌트의 역할
● 클라이언트는 엔드 서버에 직접 연결할 필요 없이 서비스를 이용할 수 있습니다.
:: REST 서버가 클라이언트와 엔드 서버 중간에서 중계 역할.
● 이러한 중계 서버로 이용하면 로드 밸런싱, 공유 메모리 등을 이용해서
확장성/성능을 향상 시킬 수 있으며 보안 정책을 적용하기도 용이합니다.
Ⅱ. REST API.
☆ REST API란?
=>> REST API는 위에서 설명한 REST 아키텍쳐를 기반으로 설계된 웹 API입니다.
◆ API ( Application Programming Interface ) 란
:: 데이터와 기능의 집합을 제공하여서, 컴퓨터 프로그램간 상호작용을 촉진하며,
상호간 정보를 교환가능 하도록 하는 것.
◆ REST API의 정의.
● REST 기반으로 서비스 API를 구현하는 것.
● 최근 OpenAPI, MSA 등을 제공하는 업체 대부분은 REST API를 제공.
◆ REST API의 탄생 배경.
● 웹의 장점을 최대한 활용할 수 있는 아키텍쳐로써 REST가 발표됨.
◆ REST API의 주요 특징.
- 자원(Resource) 중심: HTTP URI를 통해 자원을 식별합니다 => HTTP를 지원하는 프로그램 언어로 클라이언트-서버를 구현할 수 있습니다.
- HTTP 메소드 활용: GET, POST, PUT, DELETE 등의 HTTP 메소드를 사용하여 자원에 대한 CRUD 작업을 수행합니다
- 무상태성(Stateless): 각 요청은 독립적으로 처리되며, 서버는 클라이언트의 상태를 저장하지 않습니다
- 캐시 가능성: HTTP의 캐싱 기능을 활용할 수 있습니다
- 인터페이스 일관성: 표준화된 방식으로 데이터를 전송합니다
◆ REST API 설계 기본 규칙.
● 도큐먼트 : 객체 인스턴스나 데이터베이스 레코드와 유사한 개념.
● 컬렉션: 서버에서 관리하는 디렉터리하는 리소스
● 스토어: 클라이언트에서 관리하는 리소스 저장소.
1. URI는 정보의 자원을 표현해야 합니다.
● resource는 동사보다는 명사를, 대문자보다는 소문자를 사용해야합니다.
● resource는 도큐먼트 이름으로는 단수 명사를 사용해야 합니다.
● resource는 컬렉션 이름으로는 복수 명사를 사용해야 합니다.
● resource는 스토어 이름으로는 복수명사를 사용해야 합니다.
ex) GET / members/1
2. 자원에 대한 행위는 HTTP Method (GET, PUT, POST, DELETE 등) 로 표현합니다.
● URI에 HTTP Method가 들어가면 안됩니다.
ex) GET/members/delete/1 ->> DELETE/members/1
● URI에 행위에 대한 동사 표현이 들어가면 안됩니다
{즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않습니다}
ex) GET/members/show/1 -> GET/members/1
ex) GET/members/insert/2 ->> POST/members/2
● 경로 부분 중 변하는 부분은 유일한 값으로 대체합니다.
{ 즉, :id는 하나의 특정 resource를 나타내는 고유값입니다.}
ex) student를 생성하는 route:POST/students
ex) id=12인 student를 삭제하는 route: DELETE/students/12
◆ REST API 설계 시 주의할점.
- 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용한다.
ex) http://restapi.example.com/houses/apartments - URI 마지막 문자로 슬래시(/ )를 포함하지 않는다.
- URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 한다.
- REST API는 분명한 URI를 만들어 통신을 해야 하기 때문에 혼동을 주지 않도록 URI 경로의 마지막에는 슬래시(/)를 사용하지 않는다.
ex) http://restapi.example.com/houses/apartments/ (X)
- 하이픈(- )은 URI 가독성을 높이는데 사용
- 불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용해 가독성을 높인다.
- 밑줄(_ )은 URI에 사용하지 않는다.
- 밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 하므로 가독성을 위해 밑줄은 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- URI 경로에 대문자 사용은 피하도록 한다.
- RFC 3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문
- 파일확장자는 URI에 포함하지 않는다.
- REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다.
- Accept header를 사용한다.
ex) http://restapi.example.com/members/soccer/345/photo.jpg (X)
ex) GET / members/soccer/345/photo HTTP/1.1 Host: restapi.example.com Accept: image/jpg (O)
- 리소스 간에는 연관 관계가 있는 경우
- /리소스명/리소스 ID/관계가 있는 다른 리소스명
ex) GET : /users/{userid}/devices (일반적으로 소유 ‘has’의 관계를 표현할 때)
- /리소스명/리소스 ID/관계가 있는 다른 리소스명
◆ REST API 작동 방식.
1. 클라이언트가 서버에 요청을 보냅니다.
2. 서버는 클라이언트를 인증하고 권한을 확인합니다.
3. 서버가 요청을 처리합니다.
4. 서버가 클라이언트에 응답에 맞는 값을 반환합니다
Ⅲ. RESTful API.
◎ RESTful API는 REST 아키텍쳐의 제약 조건을 준수하며,
REST API의 설계 원칙을 충실히 따르는 API를 의미합니다!
◆ HTTP 와 URI 기반으로 자원에 접근할 수 있도록 제공하는 앱 개발 인터페이스.
기본적으로 HTTP 메소드와 URI 만으로 인터넷에 자료를 CRUD 가능합니다!
◆ 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 할 수 있습니다.
◆ RESTful은 REST를 REST 답게 쓰기 위한 방법으로,
누군가가 공식적으로 발표한 것은 아닙니다.
=== 즉, REST 원리를 따르는 시스템은 RESTful이란 용어로 지칭됩니다.
◎ RESTful API의 목적.
● 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것.
● RESTful한 API를 구현하는 근본적인 목적이 성능 향상 측면이 아니라,
일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것!!
=> 성능 측면에서는 굳이 RESTful한 API를 구현할 필요는 없습니다.
● RESTful 하지 못한 경우.
√ ex) CRUD 기능을 모두 POST로만 처리하는 경우.
√ ex) route에 resource,id 외의 정보가 들어가는 경우 (/students/updateName)
◎ RESTful API의 개발 원칙.
A. 자원을 식별할 수 있어야 합니다.
● URI (Uniform Resource Locator) 만으로 내가 어떤 자원을 활용/제어하려고 하는지 알 수 있어야합니다.
== 자원을 제어하기 위해서 자원의 위치는 물론 자원의 종류까지 알 수 있어야 한다는 의미.
● 서버단에서 제공하는 정보는 JSON 형태로 HTTP body에 포함되어 전송시킵니다.
B. 행위는 명시적이어야 합니다.
● REST는 아키텍처 혹은 방법론과 비슷합니다. (강제적이지 않다는 의미)
-> 기존처럼, GET을 이용해서 UPDATE와 DELETE를 해도 상관없습니다.
[단, 이건 REST를 따른다고 할 수 없습니다. ]
C. 자기 서술적이어야 합니다.
● 데이터에 대한 메타정보만 가지고도, 어떤 종류의 데이터인지,
데이터를 위해서 어떤 앱을 실행해야 하는지를 알 수 있어야 합니다.
● 즉, 데이터 처리를 위한 정보를 얻기 위해서,
데이터 원본을 추가로 읽어야 한다면 자기 서술적이지 못합니다.
REST의 단점들.
1. REST는 point-to-point 통신모델을 기본으로 합니다.
- 서버와 클라이언트가 연결을 맺고 상호작용해야하는 앱의 개발에는 적당하지 않습니다.
2. REST는 URI, HTTP 이용한 아키텍쳐링 방법에 대한 내용만을 담고 있습니다.
- 보안과 통신규약 정책은 전혀 다루지 않습니다.
- 개발자는 통신과 정책에 대한 설계와 구현을 따로 진행해야 합니다.
3. HTTP에 상당히 의존적입니다.
- REST는 설계 원리이기 때문에 HTTP와는 상관없이 다른 프로토콜에서도 구현할 수 있기는 하지만
자연스러운 개발이 힘듭니다.
- 다만 REST를 사용하는 이유가 대부분의 서비스가 웹으로 통합되는 상황이기에
큰 단점이 아니게 되었습니다.
4. CRUD 4가지 메소드만 제공합니다.
대부분의 일들을 처리할 수 있지만, 4가지 메소드만으로 처리하기에는 모호한 표현이 있습니다.
'면접준비[프론트,백,데이터,CS] > InterView 준비 [ 백엔드 ]' 카테고리의 다른 글
| [ 백엔드 면접준비 : Java&Kotlin + SpringBoot ] Java 면접 질문 정리_02 (2) | 2024.12.20 |
|---|---|
| [ 백엔드 면접준비 : Java&Kotlin + SpringBoot ] Java 면접 질문 정리_01 (0) | 2024.12.20 |
| [ 백엔드 면접 준비 ] 백엔드 면접 준비 _ 02. (0) | 2024.12.16 |
| [ 백엔드 면접 준비 ] 백엔드 면접 준비 _ 01. (2) | 2024.12.13 |
| [ 백엔드 면접 준비 ] 블로킹 vs 논블로킹 // 동기 vs 비동기 (0) | 2024.12.09 |