REST API 기본 정리

📌  REST란 (REpresentational State Transfer)?

 

HTTP를 기반으로 클라이언트가 서버의 리소스에 접근하는 방식을 규정한 아키텍처.

---

🏁  REST 특징

 

◾  Uniform

 

URI로 지정한 리소스에 대한 조작을 한정적이고 통일된 인터페이스로 수행하는 아키텍쳐다.

-->  REST가 지정한 API대로만 조작하게 하니까 !

 

◾  Stateless

 

작업을 위한 상태 정보를 저장하거나 관리하지 않습니다.

API server는 들어오는 요청만 처리하면 되기 때문에 서비스의 자유도가 높아지고 구현이 단순해진다.

-->  요청만 단순하게 처리 !

 

◾  Cacheable

 

REST는 HTTP라는 기존 웹 표준을 그대로 사용하기 때문에 웹에서 사용하는 기존 인프라를 활용할 수 있다.

따라서, HTTP가 가진 캐싱 기능을 적용할 수 있다.

-->  Last-Modified Tag / E-Tag 활용가능 !

 

◾  Self-descriptiveness

 

REST API만 보더라도 HTTP 요청의 내용을 이해할 수 있다.

 

◾  Client-Server 구조

 

서버는 API만 제공하고

클라이언트는 사용자 인증이나 context (로그인 정보, 세션)만 관리하게 되므로 각자의 역할이 확실하게 구분되었다.

고 하는데 이 내용은 더 공부해봐야겠다

 

◾  hierarchical 구조

 

REST를 이용해 다중 계층의 서버를 구축할 수 있다.

보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고

PROXY나 게이트 웨이 같은 네트워크 기반의 중간 매체도 활용할 수 있다.

아직 무슨 말인지 모르겠다

 

 

📌  REST API란?

 

REST를 기반으로 서비스 API를 구현한 것.

 

REST API의 구성 요소 3가지

✔  자원 (resource)
✔  행위 (verb)
✔  표현 (representation)

---

🏁  설계 원칙

 

◾  URI는 리소스(자원)를 표현해야 한다.

 

#bad
GET /get Todos/1

#good
GET /todos/1

 

URI는 리소스를 표현하는 데 중점을 둬야하기 때문에, 동사보다는 명사로 이름을 설정해야 한다. ( 명령어는 out! out! )

 

 

◾  리소스(자원)에 대한 행위는 HTTP 요청 메서드로 표현한다.

 

#bad
GET /todos/delete/1

#good
DELETE /todos/1

 

리소스에 대한 행위는 HTTP 요청 메서드를 통해 표현하며 URI에 표현하지 않는다.

HTTP 요청 메서드는 GET, POST, PATCH, DELETE 등을 사용한다.

 

 

📍   HTTP 요청 메서드 (일부)      REST API 규칙

 

GET

특정 리소스를 조회만 한다.

 

POST

특정 리소스를 생성한다.

 

PUT

원하는 데이터로 특정 리소스 전체를 수정한다.

 

PATCH

원하는 데이터로 특정 리소스 일부를 수정한다.

 

DELETE

특정 리소스를 삭제한다.

 

 

📍   PUT과 PATCH의 차이

 

언뜻보면 응 전체와 일부 ~ 하면서 넘어갈 수 있지만 예시를 보면 읭 ? 스럽다.

동일한 body의 요청을 보내면 똑같은 결과가 나오기 때문이다.

 

 

하지만 body가 모든 data를 포함하지 않았을 때, 둘의 차이점이 생긴다.

PUT은 정말 전체를 수정하기 때문에 존재하지 않는 키 값에 대해서는 null 처리를 하고,

PATCH는 부분을 수정하기 때문에 존재하지 않는 키 값은 건드리지 않는다.

 

 

 

📌  HTTP 상태 메세지 (Status Codes)

 

200 - OK

요청 수행 완료 😉

 

201 - CREATED

리소스 생성 요청 수행 완료 (생성되었습니다😉)

 

204 - NO CONTENT

리소스 삭제 요청 수행 완료 (삭제되었습니다😉)

 

304 - NOT MODIFIED

요청이 이미 캐쉬되어 있는 경우 && 요청 데이터가 변경되지 않았을 경우

요청하는 정보를 이미 디스크에 가지고 있을 경우에 (캐시되어 있는 경우)

브라우저는 이 데이터가 변경되었는지 여부를 확인하는 요청을 보낸다.  -->  Conditional Get Request

서버는 요청 데이터가 변경되지 않았을 경우 304를 리턴하고, 변경되었을 경우 변경된 데이터로 응답을 보낸다.

 

400 - BAD REQUEST

삐빅 요청이 부적절했거나, 들어줄 수 없는 요청일 경우

 

401 - UNATHORIZED

삐빅 해당 요청을 하려면 사용자 인증이 필요합니다

 

403 - FORBIDDEN

삐빅 해당 요청에 대한 응답은 있는데 접근할 수 없기 때문에 거절합니다

이 경우는 해당 리소스가 존재한다는 걸 알리는 에러이기 때문에 400이나 404를 사용할 것을 권장.

 

404 - NOT FOUND

삐빅 해당 요청의 리소스를 찾을 수 없습니다

 

500 - INTERNAL SERVER ERROR

삐빅 서버에 문제가 있습니다

API 개발자들은 이 문제를 필히 피해야합니다.

 

 

참고 문서

Conditional GET Request

REST API 규칙

5 Basic REST API Design Guidelines