오늘은 부트캠프 39일차이다. 오늘은 늘 해왔듯이 알고리즘 1개와 숙련강의를 듣고 과제를 끝냈고, TIL 작성하는 강의와 REST API에 대한 강의를 들었다. 예전에 REST API에 대한 글을 잠깐 본 적이 있었는데, 그 때는 이게 뭐지 하면서 그냥 아~~ 이런게 있구나라고 생각하고 지나갔는데 이제는 이걸 실전에서 써야하는 입장에서 다시 강의를 들어보니 완벽히는 아니지만 조금은 알 것 같다는 느낌이 들었다.
오늘 배운 것
1. REST API의 탄생
-REST는 Representational State Transfer라는 용어의 약자로서 2000년도에 로이 필딩의 박사학위 논문에서 최초로 소개되었다.
-HTTP의 주요 저자 중 한 사람으로 그 당시(HTTP) 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 안타까워하며
웹의 장점을 최대한 활용할 수 있는 아키텍처로서 REST를 발표했다고 한다.2. REST 구성
-자원(RESOURCE)-URI
-행위(Verb)-HTTP METHOD
-표현(Representations)3. REST의 특징
3-1. Uniform(유니폼 인터페이스)
-Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일이다.
3-2. Stateless(무상태성)
-REST는 무상태성 성격을 갖는다. 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
3-3. Cacheable(캐시 가능)
-HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그래로 활용이 가능하다.
3-4. Self-decriptiveness(자체 표현 구조)
-REST API 메세지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것이다.
3-5. Client-Server 구조
-REST 서버는 API 제공, 클라이언트는 사용자 인증이나 켄텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이
확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 된다.3-6. 계층형 구조
-REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY,
게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.4. REST API 디자인 가이드
-URI는 정보의 자원을 표현해야 한다.
-자원에 대한 행위는 HTTP(GET, POST, PUT, DELETE)로 표현한다.5. HTTP METHOD의 알맞은 역할
5-1. POST
- POST를 통해 해당 URI를 요청하면 리소스를 생성
5-2. GET
-GET를 통해 해당 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
5-3. PUT
-PUT를 통해 해당 리소스를 수정한다.
5-4. DELETE
-DELETE를 통해 리소스를 삭제한다.
6. URI 설계 시 주의할 점
6-1. 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
EX)
http://restapi.example.com/houses/apartments
http://restapi.example.com/animals/mammals/whales6-2. URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
EX)
http://restapi.example.com/houses/apartments/ (X)
http://restapi.example.com/houses/apartments (0)6-3. 하이픈(-)은 URI 가독성을 높이는 데 사용
-불가피하게 긴 URI경로를 사용하게 된다면 하이픈을 사용한다.
6-4. 밑줄(_)은 URI에 사용하지 않는다.
밑줄 때문에 문자가 가려지기 때문이다.
6-5. URI 경로에는 소문자가 적합하다.
-대소문자에 따라 다른 리소스로 인식할 수 있기 때문이다.
7. HTTP 응답 상태 코드
7-1. 200
-클라이언트의 요청을 정상적으로 수행함.
7-2. 201
-클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시)
7-3. 400
-클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드
7-4. 401
-클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드
EX) 로그인하지 않은 유저가 로그인 했을 때 가능한 리소스를 요청했을 때7-5. 403
-유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드
7-6. 405
-클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드
7-7. 301
-클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드
-응답 시 Location header에 변경된 URI를 적어 줘야 한다.7-8. 500
-서버에 문제가 있을 경우 사용하는 응답 코드
