REST API

REST(Representational State Transfer) API

• 로이 필딩의 박사 학위 논문에서 처음 소개
• 웹에서 사용되는 데이터나 자원(Resource)을 HTTP URI로 표현하고, HTTP 프로토콜을 통해 요청과 응답을 정의 하는 방식
• 표준화된 HTTP API를 만드는(디자인하는)것이라고 생각하면 된다. 

 

좋은 REST API를 디자인하는 방법

• 레오나르드 리차드슨은 REST APIU를 잘 적용하기 위한 4단계 모델을 만들었다.
• 0단계부터 3단계
• 로이필딩은 모든 단계를 충족해야 REST API라고 했지만, 3단계 까지도 지키기 어렵기 때문에 2단계 까지만 적용해도 좋은 API 디자인 이라고 볼수있다. 이 경우에 HTTP API라고도 부른다.

0단계	HTTP 사용
1단계	개별 리소스와의 통신 준수
2단계	HTTP 메소드 원칙 준수
3단계	HATEOAS 원칙 준수

 

REST 성숙도 모델 - 0단계

• 단순히 HTTP 프로토콜을 사용하기만 해도 된다.
• 좋은 REST API를 작성하기 위한 기본 단계

 

REST 성숙도 모델 - 1단계

• 웹에서 사용되는 데이터와 리소스를 HTTP URI로 표현
• 개별 리소스에 맞는 엔드포인트를 사용해야 한다.

// E35 좌석을 예매한다.

// 요청
POST /seat/E35 HTTP/1.1
[헤더]

{
	"name" : "me"
    "date" : "2023-05-05"
}

// 응답

HTTP/1.1 200 OK
[헤더]

{
  "seat" : [
  	{"id": "E35", "name" : "me", "date" : "2023-05-05", ...}
  "status": 예약되었습니다.    
  ]
}

• /seat/E35 라는 엔드포인트를 통해 E35 좌석에 개별적으로 접근하여 예약을 했다.
• 엔드포인트 작성시 동사, HTTP메서드 등을 지양하고, 리소스에 집중하여 명사 형태에 단어로 작성하는것이 좋다.
• 응답시에 리소스 사용에 대한 정보와 함께 리소스 사용에 대한 성공/실패 여부를 반환 해야한다.

 

REST 성숙도 모델 - 2단계

• CURD에 맞게 적절한 HTTP 메서드를 사용하는것에 중점을 둔다.
• 리소스 조회(READ)시 GET, 리소스 추가(CREATE)시 POST, 리소스 삭제(DELETE)시 DELETE, 리소스 변경(UPDATE)시 PUT
• 응답코드도 CREATE시 200이 아닌 201 Created, 관련 리소스를 응답메시지 헤더에 Location을 추가하여 작성된 URI를 확인할수 있도록 해야 한다.
• 메서드 사용 규칙
  • GET은 서버의 데이터를 변화 시키지 않아야 한다.
  • POST는 요청마다 새로운 리소스를 생성, PUT은 요청마다 같은 리소스를 반환(멱등성) 하기때문에 구분
  • PUT과 PATCH도 구분, PUT은 교체, PATCH는 수정
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods 메서드 정리
• 여기까지만 적용해도 모범적인 HTTP API라고 할 수 있다.

 

REST 성숙도 모델 - 3단계

• HATEOAS(Hypertext As The Engine Of Application State), 하이퍼미디어 컨트롤을 적용
• 응답에는 리소스의 URI를 포함한 링크 요소를 삽입하여 작성해야 한다.
• 링크요소는 응답을 받은 다음에 할 수 있는 다양한 액션들을 위해 많은 하이퍼미디어 컨트롤을 포함하고 있다.
• 예를 들면 좌석을 조회시 조회된 좌석을 예약할수있는 링크를 삽입하는것
• 응답내에 새로운링크를 넣어 새로운 기능에 접근 할수 있도록 하는것