[REST API] ~Section 1. REST API 및 프로젝트 소개

REST API

• API: Application Programming Interface
• REST
  • REpresentational State Transfer
  • 인터넷 상의 시스템 간 상호 운용성(interoperability)을 제공하는 방법 중 하나
  • 각 시스템의 독립적인 진화를 보장하기 위한 방법
  → REST API: REST 아키텍쳐 스타일을 따르는 API

 

REST Architecture Style

Day1, 2-2. 그런 REST API로 괜찮은가

• 오늘날 대부분의 REST API라고 불리는 것들은 REST API라고 할 수 없다. REST API라고 할 수 있으려면 다음과 같은 아키텍쳐 스타일을 따라야 한다.

📌 REST Architecture Style

1. Client-Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-On-Demand(optional)

📌 Uniform Interface

1. Identification of resources
2. Manipulation of resources through representations
3. self-descriptive messages
4. Hypermisa as the engine of aplication sate (HATEOAS)

• 특히 Uniform Interface를 구성하는 요소들 중에서도 self-descriptive messages, hypermisa as the engine of application state (HATEOAS)를 만족하지 않기 때문에 REST API라고 할 수 없다.
• 나머지 architecture들은 HTTP만 사용하더라도 쉽게 달성할 수 있다.

📌 Self-descriptive message

• 메시지 스스로 메시지에 대한 설명이 가능해야 한다.
• 서버가 변해서 메시지가 변해도 클라이언트는 그 메시지를 보고 해석이 가능하다.
• 확장 가능한 커뮤니케이션
  → 메시지 자체가 본문에서 메시지에 대한 설명을 다 하고 있기 때문에 메시지가 변하더라도 이 메시지를 받는 클라이언트는 서버가 메시지를 바꾸더라도 알아서 대응할 수 있어야 한다.

📌 Self-descriptive message 해결 방법

1. 미디어 타입을 정의하고 IANA에 등록한 후, 그 미디어 타입을 리소스 리턴할 때 Content-Type으로 사용 → GitHub REST API 방식
2. profile 링크 헤더를 추가
   • 브라우저들이 아직 스팩 지원을 잘 안해, 대안으로 응답 본문에 profile 링크를 HAL 스펙에 따라 넣어준다.

 

📌 HATEOAS

• 하이퍼미디어(링크)를 통해 애플리케이션 상태 변화가 가능해야 한다.
• 링크 정보를 동적으로 바꿀 수 있다. (Versioning 할 필요 없이!)

→ 어떤 응답을 받았던, 그 응답을 받은 다음에 다음 애플리케이션 상태로 전의를 하려면 이 애플리케이션의 서버가 보내준 응답에 들어있는 하이퍼미디어, 링크 정보를 사용해 이동해야 한다.

 

📌 HATEOAS 해결 방법

1. 데이터에 링크 제공
   • 링크를 어떻게 정의할 것인가? → HAL(Hypertext Application Language) 스펙 사용
2. 링크 헤더나 Location을 제공 </aside>

 

Event REST API

이벤트 등록, 조회, 수정 REST API를 만들어보자!

 

GET /api/events

이벤트 목록 조회 REST API (로그인 안 한 상태)

• 응답 데이터
  • 이벤트 목록
  • 링크
    • self
    • profile: 이벤트 목록 조회 API 문서로 링크(문서는 스프링 REST Docs로 만들 예정)
    • get-an-event: 이벤트 하나 조회하는 API 링크
    • next(optional): 다음 페이지
    • prev(optional): 이전 페이지

이벤트 목록 조회 REST API (로그인 상태)

• 응답 데이터
  • 이벤트 목록
  • 링크
    • self
    • profile: 이벤트 목록 조회 API 문서로 링크
    • get-an-event: 이벤트 하나를 조회하는 API 링크
    • create-new-event: 이벤트를 생성할 수 있는 API 링크(로그인 상태에서만 가능)
    • next(optional): 다음 페이지
    • prev(optional): 이전 페이지

 

POST /api/events

이벤트 생성

 

GET /api/events/{id}

이벤트 하나 조회

 

PUT /api/events/{id}

이벤트 수정

 

Event 도메인 구현

Event entity에 Lombok annotation 추가

@Getter @Setter @EqualsAndHashCode(of = "id")
@Builder @NoArgsConstructor @AllArgsConstructor
public class Event {
}

• Entity에다가 @Data annotaion을 사용하면 안된다. 상호 참조 떄문에 stack overflow가 발생할 수 있다.
• 아직은 annotation을 더 줄일 수 있는 방법은 없다.