내가 공부하고 싶어서 써논 글
REST API의 구성
Rest API는 다음처럼 구성되어있다고 한다.
- 자원 - URI
- 행위 - HTTP METHOD
- 표현
RST API의 특징
- uniform Interface
Uniform Interface는 URI로 지정한 리소스에 대해 조작을 통일되고 한정적인 인터페이스로 수행하는 스타일을 말한다. - Stateless
REST는 무상태성 성격을 가지는데 이 말은, 작업을 위한 상태정보를 따로 저장하고 관리하지 않는 다는 뜻이다. - Cacheable
REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 그대로 사용한다. 즉 HTTP가 가진 캐싱 기능이 적용 가능하다. - Client-Server
REST는 클라이언트와 서버에서 개발 해야할 내용이 명확해지고 서로간 의존성이 줄어든다. - 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있다. PROXY, 게이트웨이 같은 네트워크 기반의 미들웨어를 사용할 수 있게 한다.
REST API DISIGN
- URI는 정보의 자원을 표현해야 한다.
- 리소스명은 명사를 사용한다.
GET /resources/1같은 형식으로 작성해야 한다.
- 행위는 GET, POST, PUT, DELETE 로 작성한다.
GET /resources/get/1 (X)
GET /resources/show/2 (X)같은 형태는 위배된다.
CRUD 역할
- POST : 리소스 생성
- GET : 리소스 조회
- PUT : 리소스 수정
- DELETE : 리소스 삭제
주의점
- (/)는 계층을 나타내는 곳에 사용한다
XXXX.com/animals/birds/pinch- URI 마지막엔 슬래시를 포함하지 않는다
- 긴 경로의 URI는 (-)을 사용하여 표시한다.
- (_)는 사용하지 않는다
- 대문자는 사용하지 않는다
대소문자를 구분하기 때문에 다른 리소스로 인식된다.
응답상태 코드
- 200
클라이언트의 요청을 정상적으로 수행 - 201
클라이언트가 리소스 생성을 요청하고, 성공적으로 생성됨 - 400
클라이언트의 요청이 부적절한경우 사용 - 401
인증되지 않은 클라이언트의 요청 - 403
응답하고 싶지 않은 리소스 요청시 - 301
요청 리소스의 URI 변경시 사용 - 500
서버에 문제가 있을 경우 사용
마지막
REST API의 사용법에 대해서 간단하게 공부를 해보았다. 제작한 백엔드 프로젝트에서 나름 REST API를 지켜서 만들어 보아야겠다라고 한것들이 모두 엉터리였다. 상태 코드도 하나도 맞지 않고, 이번 공부를 마치고 직접 다시 서버 요청에 관련된 코드들을 모두 고쳐볼 생각이다.
