[TIL] 네트워크 - REST API

Today I Learned

REST API

REST API란

• Representational State Transfer
• 2000년 로이 필딩(Roy Fielding, HTTP의 주요 저자 중 한 사람)은 자신의 박사학위 논문에서 웹(HTTP)의 장점을 최대한 활용할 수 있는 아키텍처로 REST를 소개하였다. REST는 특정 기술이아닌, 네트워크 아키텍처 원리의 모음이다. REST는 HTTP 프로토콜을 의도에 맞게 디자인하도록 유도하며 REST의 기본 원칙을 지킨 디자인을 RESTful하다고 표현한다.

REST API 중심 규칙

1. URI는 정보의 자원을 표현한다
   • 리소스명은 명사를 사용
   • 리소스명에 행위를 나타내는 동사를 사용해서는 안됨
2. 자원에 대한 행위는 HTTP Method로 표현한다
   • POST (Create) : 리소스 생성 (Request에 포함된 Entity를 Request URI에 정의된 리소스 하위 Entity에 새롭게 생성, 각 요청마다 새로운 결과값 제공)
   • GET (Read) : 리소스 조회
   • PUT (Update) : 리소스 전체 업데이트 (Request URI에 있는 리소스를 Request에 포함된 Entity 값으로 갱신, 멱당한 결과값 제공)
   • PATCH (Update) : 리소스 일부 업데이트
   • DELETE (Delete) : 리소스 삭제

REST API의 구성

• 자원 (Resource) : URI
• 행위 (Verb) : HTTP Method
• 표현 (Representations) : HTTP Payload

Richardson Maturity Model

• 레너드 리처드슨(Leonard Richardson)이 제시한 REST를 성숙도에 따라 단계별로 나눈 모델
• 실제로는 REAT API의 3단계를 모두 만족시키는 API는 찾아보기 힘들다. 하지만 적어도 2단계까지는 지켜 API를 작성하자.

Level 0 : The Swamp of POX

• HTTP 프로토콜을 사용

Level 1 : Resources

• 요청하는 리소스에 따라 각각 다른 엔드포인트로 구분
• 개별 리소스(해당 서버가 가진 자원)와의 통신 준수
• 요청시 리소스를 구체적으로 구분
• 요청이 대해 잘 이루어졌는지 응답 body에서 보여줌
• URI : 동어 반복X, spinal-case

Level 2 : HTTP Verbs

• CRUD에 맞게 적절한 HTTP 메소드 사용
• GET, POST, PUT, PATCH, DELETE 구분하여 사용
• GET은 body를 가지지 않기 때문에 쿼리 파라미터(?키=값)로 특정
• 응답에서 상황에 맞는 status code를 사용

Level 3 : Hypermedia Controls

• HAGEOAS (Hypertext As The Engine Of Application State) 적용
• 응답에 리소스의 URI를 포함한 링크(응답을 받은 뒤 할 수 있는 액션을 위한 하이퍼미디어 컨트롤을 포함한 링크)를 삽입하여 작성