[Server] Rest API

 Rest API

 

이번에는 Rest API 에 대해 알아보려고 합니다.

Rest API 를 알기 전에는 API 개념부터 알아야 하는데요.

우리가 살고있는 세계에서는 다양한 기계들이 존재합니다.

이 기계의 기능을 사용자가 사용하려면 제어장치를 만들어야 합니다.

 

 

 

예를 들면 TV 는 사용자가 TV 를 키고 끄고, 채널을 변경하고, 음량을 조절하는 리모콘이 있으며

컴퓨터는 컴퓨터를 동작하고 화면을 제어하는 키보드와 마우스가 있습니다.

사람과 기계 사이에 존재해 둘을 연결시켜주는 역할을 하고 있는데요.

이런 것들을 Interface(인터페이스) 라고 부릅니다. 이렇게 인터페이스가 존재하면

기계의 내부 구성을 몰라도 쉽고 간편하게 조작할 수 있습니다.

 

 

소프트웨어 영역에서는 interface 를 UI(User Interface) 라고 부르는데요.

컴퓨터나 스마트폰을 켜보면 사용자들이 프로그램, 사이트, 앱을 원하는대로 제어하고 정보를  볼 수 있도록

버튼, 스크롤바, 슬라이더, 브라우저 창 등 소프트웨어적인 장치들이 마련되어 있습니다. 이것들을 UI 라고 합니다.

UI 는 소프트웨어와 사람과의 소통을 위한 것입니다.

 

그런데 IT 세계에서는 UI 처럼 직접 눈에 보이는 영역보다 보이지 않은 영역들이 더 많은데요.

기계와 기계 또는 소프트웨어와 소프트웨어 사이에서도 수많은 정보 요청과 교환이 이루어집니다. 이들끼리도

소통할 수 있는 무언가가 필요한데요. 소프트웨어가 다른 소프트웨어로부터 지정된 형식으로 요청, 명령을

받을 수 있는 수단을 API(Application Programming Interface) 라고 합니다.

 

Rest API 에서 REST 는 REpresentional State Transfer 의 약자로

자원의 이름으로 구분하여 해당 자원의 상태를 교환하는것을 의미합니다.

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에

웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이라고 말할 수 있습니다.

자원의 표현(Representional)

자원은 데이터, 사진, 동영상과 같이 해당 소프트웨어에서 관리되어 있는 모든 것을 의미합니다.

표현은 자원을 표현하기 위한 이름입니다.

ex) members(DB에 회원 정보가 자원일 때)

자원의 상태(State)

데이터가 요청될 때 전달되는 데이터의 상태입니다. 대부분 JSON, XML 을 사용합니다.

 

̱REST 구성 요소

 

1.Resource(자원)

모든 자원에는 고유한 식별자가 존재하는데, 이 자원은 Server 에 존재합니다.

자원을 식별하는 이 식별자는 "/members/{id}"  와 같은 HTTP URI 입니다.

클라이언트는 URI 를 활용해서 자원을 지정해 서버에 요청하면 서버는 그에 해당하는 자원을 응답합니다.

 

2. Verb(행위)

HTTP 메서드 GET, POST, PUT, PATCH, DELETE 를 사용합니다.

 

HTTP 메서드	행위
GET	Read: 자원 조회, 정보 요청
POST	Create: 자원 생성
PUT	Update: 데이터 전체를 갱신
PATCH	Update: 데이터 일부분만 갱신
DELETE	Delete: 데이터 삭제

 

3. Represention(표현)

Client 와 Server 가 데이터를 주고 받는 형태이며 JSON, XML, TEXT 등이 있습니다.

일반적으로 JSON, XML 를 사용합니다.

 

REST 의 특징

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

구성 요소(클라이언트, 서버 등) 사이의 인터페이스는 균일(uniform)한 아키텍쳐 스타일입니다.

인터페이스를 일반화함으로써, 전체 시스템 아키텍처가 단순해지고, 상호 작용의 가시성이 개선되며, 

구현과 서비스가 분리되므로 독립적으로 발전시킬 수 있습니다.

 

2 Stateless (무상태성)

클라이언트와 서버의 통신에 상태가 없어 쿠키나 세션정보를 저장하고 관리하지 않고 단순 요청을 처리하면 됩니다.

요청 하나만 봐도 바로 뭔지 알 수 있으므로 가시성이 개선되고,

Server 의 처리 방식에 일관성이 부여되어, 자유도가 높아집니다.

 

3. Client - Server 구조

Client 는 사용자 인증이나 context(세션, 로그인 정보 등) 을 직접 관리합니다.

Server 는 리소스를 가지고 있고 API 를 제공합니다.

각자 역할을 확실히 구분해 개발할 내용이 명확해지고 서로간의 의존성이 줄어듭니다.

 

4. Cacheable (캐시 가능)

웹 표준인 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존 인프라를 그대로 활용할 수 있습니다.

그러므로 HTTP 가 가진 캐싱 기능을 사용할 수 있습니다. 대량의 요청을 효율적으로 처리할 수 있어

용량이나 성능 측면에서 매우 큰 장점입니다.

 

5.  Layered System(계층형 구조)

REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조를 변경할 수 있어

구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.

 

6. Self-descriptiveness (자체 표현 구조)

REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어

있다는 것입니다. 

 

̱ REST API 설계 규칙

 

1. URI는 정보의 자원을 표현해야 합니다.

자원은 동사보다는 명사를, 대문자보다는 소문자를 사용합니다.

자원이 컬렉션이라면 복수 명사를 사용해야 합니다.

ex) GET /members/1

 

2. 자원에 대한 행위는 HTTP Method (GET, POST, PUT, DELETE)로 표현합니다.

URI에 HTTP Method가 들어가면 안됩니다.

ex) GET /members/delete/1 -> DELETE /members/1

 

URI에 행위에 대한 동사 표현이 들어가면 안됩니다. 즉, CRUD 기능을 나타내는 것은 URI에 사용하지 않습니다.

ex) GET /members/join/1 -> POST /members/1

 

경로 부분 중 변하는 부분은 유일한 값으로 대체합니다.

즉, id는 하나의 특정 resource를 나타내는 고유값을 의미합니다.

ex) id=1 인 member 를 삭제하는 URI: DELETE / members/1

 

3. 슬래시 구분자(/ )는 계층 관계를 나타내는데 사용합니다.

 

4. URI 마지막 문자로 슬래시(/ )를 포함하지 않습니다.

 

5. URI에 포함되는 모든 글자는 리소스의 유일한 식별자로 사용되어야 하며 

URI가 다르다는 것은 리소스가 다르다는 것이고, 역으로 리소스가 다르면 URI도 달라져야 합니다.

 

6. 하이픈(- )은 URI 가독성을 높이는데 사용할 수 있습니다.

 

7. 밑줄( _ )은 URI에 사용하지 않습니다.

 

8. URI 경로에는 소문자가 적합합니다.

URI 경로에 대문자 사용은 피하도록 합니다.

 

9. 파일 확장자는 URI에 포함하지 않습니다. Accept header를 사용하도록 합니다.

ex) GET /files/jdk18.exe HTTP/1.1 Host: edwith.org Accept: image/jpg (O)

 

10. 리소스 간에 연관 관계가 있는 경우 다음과 같은 방법으로 표현합니다.

/리소스명/리소스 ID/관계가 있는 다른 리소스명

ex) GET : /members/{memberId}/orders (일반적으로 소유 ‘has’의 관계를 표현할 때)

 

̱ REST API 설계 예시

 

CRUD	HTTP Method	Path
회원의 전체 목록 가져오기	GET	/members
회원중 하나 가져오기	GET	/member/{id}
회원 생성	POST	/member (회원 가입할 때 회원의 식별자는 회원의 정보가 추가되면서 생성되므로 post 요청에서는 작성할 필요가 없음)
회원 수정	PUT	/member/{id}
회원 삭제	DELETE	/member/{id}

 

Rest API 는 HTTP  요청을 보낼 때 정보들이 주고받아지는 데 있어서 개발자들이 널리 쓰이는 일종의 약속입니다.

앞에서 설명했듯이 형식이기 때문에, 기술에 구애받지 않습니다. 앱을 만들든, 웹사이트를 만들든

어떤 프로그래밍 언어를 쓰든 소프트웨어간 HTTP 로 정보를 주고받는 부분이 있다면 위 형식과 규칙을 준수해서

Restful 한 서비스를 만들 수 있습니다.  REST 의 규칙을 지켜서 설계된 API 를 RESTful API 라고 하며

RESTful API 는 요청을 보내는 주소만으로 어떤 자원을 요청 하는지 파악할 수 있습니다.

 

이 포스팅은 https://www.youtube.com/watch?v=iOueE9AXDQQ 의 내용과

https://www.boostcourse.org/web326/lecture/58986?isDesc=false 의 내용을 참고하여 작성하였습니다.