REST API란?
GOAL
- REST API의 탄생
- REST API란
- REST API의 특징
- HTTP 상태 응답 코드
REST API의 탄생
REST(Representational State Transfer) 의 약어로 1998 Roy T. Fielding이 Microsoft Research에서 최초로 소개했으며 2000년에는 박사 학위 논문으로 발표되었습니다.
로이 필딩은 HTTP 프로토콜 설계 작업에 참여한 대학원생이었으며 기존에 구축되어있는 웹하고 호환성 http 명세에 대한 기능을 고치고 추가하면서 어떻게 웹을 망가뜨리지 않고 HTTP를 진보시킬 수 있을까?라는 고민에서 시작되었습니다.
REST API란?
REST 아키텍처 스타일을 따르는 API으로서 HTTP를 이용해서 통신할 때 HTTP가 가진 잠재력을 최대한 이용하게 해주는 형식입니다.
REST의 구성
- 자원(RESOURCE) - URI
- 행위(Verd) - HTTP METHOD
- 표현(Representations)
REST의 특징
- Uniform Interface (유니폼 인터페이스) : HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 사용이 가능한 인터페이스 스타일입니다. 안드로이드 플랫폼, IOS 플랫폼 등 특정 언어나 플랫폼에 종속되지 않고 사용이 가능합니다.
- identification of resurces: 리소스가 uri로 식별하면 됩니다. 요청 내에 기술된 자원을 식별할 수 있어야 합니다.
- manipulation of resources through representation: 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것입니다.
- self-descriptive message: 메세지만 보고도 이해할 수 있게 스스로를 설명할 수 있게 충분한 정보를 포함해야 합니다.
- hypermedia as the engine of application stats(HATEOAS): 애플리케이션 상태는 hyperlink를 이용해 전이되어야 합니다.
- Stateless: REST는 상태 정보를 유지하지 않는다. 서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리를 합니다. 이전 요청이 다음 요청 처리에 연관이 되면 안 됩니다.
- Cacheable: HTTP의 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능합니다.
- Client-Server: REST 서버는 API 제공을 하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리합니다. 서로 간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야할 내용들이 명확해집니다. 각각의 역할이 명확하게 구분되기 떄문에 서로간의 의존성이 줄어들고 각자 개발해야 될 내용도 명확해집니다.
- Layerd System: REST 서버는 다중 계층으로 구성될 수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 둘 수 있다.
위에 나온 원칙들을 지켜야 REST API라고 부릅니다. 문제는 그런 REST API로 괜찮은가 영상을 보면,self-descriptive message, HATEOAS가 현실적으로 실무에서 잘 지켜지지 않기 때문에 이는 원칙적으로 REST API라고 부를 수 없다라는 얘기가 나옵니다.
그래서 REST API라고 부르지 않던가, 아니면 원칙적으로 REST API가 아닌데, 그냥 편의상 REST API라고 부르던가 이런 얘기가 나옵니다.
REST API 중심 규칙
REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.
- URI는 정보의 자원을 표현해야 합니다. (리소스명은 동사보다 명사를 사용)
- 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현합니다.
잘못된 예시
GET /members/update/1이와 같은 방식은 REST를 제대로 적용하지 않은 URI입니다. URI는 자원을 표현해야 하고 행위가 들어가서는 안 됩니다.
위에서 말했듯이 자원 행위는 HTTP Method로 표현해야합니니다.
위의 잘못된 예제는 다음과 같이 수정할 수 있습니다.
PUT /members/1
회원 정보 추가
GET /members/insert/1 (x)
POST /members (o)
회원 정보 삭제
GET /members/delete/1 (x)
DELETE /members/1 (o)HTTP Method
다음과 같이 기본적인 4가지의 Method를 가지고 CRUD를 할 수 있습니다.
| Method | 내용 |
| GET | GET을 통해 해당 리소스를 조회합니다. |
| POST | POST 통해 해당 URI을 요청하면 리소스를 생성합니다, |
| PUT | PUT를 통해 해당 리소스를 수정합니다. |
| DELETE | DELETE를 통해 리소스를 삭제합니다. |
URI 설계 시 주의 사항
- 구분자(/)는 계층 관계를 나타날 때 사용합니다.
- URI 마지막 문자로 슬래시(/)를 사용하지 않습니다.
- 하이픈(-)은 가독성을 높이기 위해서 사용합니다.
- 밑줄(_)은 사용하지 않습니다.
- URI 경로에는 소문자가 적합합니다.
HTTP 상태 응답 코드
대표적으로 몇 가지 응답 코드를 살펴보도록 하겠습니다.
2xx(성공)
- 200(성공): 클라이언트의 요청을 정상적으로 수행합니다.
- 201(작성됨): 클라이언트에게 생성 작업을 요청받았고, 해당 리소스가 성공적으로 생성되었습니다.
4xx(요청 오류)
- 400(잘못된 요청): 클라이언트의 요청이 올바르지 않은 경우
- 401(권한 없음):이 요청은 인증이 필요합니다. 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때
- 403(Forbidden, 금지됨): 유저 인증 상태와 관계없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 (401은 인증 실패, 403은 인가 실패)
- 405(허용되지 않은 방법): 요청에 사용 불가능한 Method를 이용했을 경우. 예를 들어 POST 방식으로 요청을 받는 서버에 GET 요청을 보내는 경우
5xx(서버 오류)
- 500(내부 서버 오류): 서버에 오류가 발생하여 요청을 수행할 수 없습니다.
읽어주셔서 감사합니다.
부족한 설명이나 잘못된 내용이 있으면 댓글 남겨주시면 감사하겠습니다.
References
'CS > Network' 카테고리의 다른 글
| OAuth2 동작 흐름에 대해서 알아보자 (0) | 2021.04.10 |
|---|