REST API

CSR과 SSR의 차이

1. CSR (Client-Side Rendering)

• 정의:
  클라이언트(브라우저)에서 JavaScript로 데이터를 처리하고 동적으로 렌더링.
• 장점:
  • 필요한 데이터만 서버에서 받아 UI 업데이트.
  • 빠른 사용자 경험(페이지 리로드 없음).
  • 클라이언트 중심의 인터랙티브 서비스에 유리.
• 단점:
  • 검색엔진 최적화(SEO)에 적합하지 않음.
  • 초기 로딩 시간 증가.

2. SSR (Server-Side Rendering)

• 정의:
  서버에서 HTML 페이지를 렌더링하여 클라이언트로 전송.
• 장점:
  • 검색엔진(SEO)에 적합.
  • 초기 로딩 속도 빠름.
  • 네트워크 속도가 느린 환경에서 유리.
• 단점:
  • 서버 부하 증가.
  • 클라이언트와 서버 간 상호작용은 제한적.

 

RESTful API 설계

RESTful하게 만든다:

• 자원을 중심으로 HTTP 메서드를 사용하여 상태를 관리.
• 의미 있는 엔드포인트(URI)와 HTTP 메서드를 조합.

 

HTTP 메서드와 사용 예

HTTP 메서드 기능 설명

GET	자원 조회	서버에서 데이터를 가져옴.
POST	자원 생성, 데이터 처리	서버에 데이터를 보내거나 새로운 리소스를 생성.
PUT	데이터 전체 변경	모든 속성을 포함하여 데이터를 변경.
PATCH	데이터 일부 변경	데이터의 특정 속성만 수정.
DELETE	데이터 삭제	리소스 삭제.

 

도서 관리 RESTful API 설계

1. 도서 추가 (Create a Book)

• 메서드: POST
• URI: /books
• 요청 바디:

  {
    "title": "자바는 어려워",
    "author": "조코딩스",
    "price": 33000
  }
  

• 설명: 새로운 도서를 추가.

 

2. 도서 목록 조회 (Get All Books)

• 메서드: GET
• URI: /books
• 설명: 모든 도서의 목록을 조회.

 

3. 특정 도서 조회 (Get a Single Book)

• 메서드: GET
• URI: /books/{id}
• 설명: 특정 ID에 해당하는 도서 정보를 조회.

 

4. 도서 정보 수정 (Update a Book)

• 메서드: PATCH
• URI: /books/{id}
• 요청 바디(예시):

  {
    "price": 30000
  }
  

• 설명: 특정 도서의 일부 속성을 수정.

 

5. 도서 삭제 (Delete a Book)

• 메서드: DELETE
• URI: /books/{id}
• 설명: 특정 ID에 해당하는 도서를 삭제.

 

6. 도서 대출 (Borrow a Book)

• 메서드: POST
• URI: /loanrecords
• 요청 바디:

  {
    "bookId": 3,
    "userId": 11,
    "loanDate": "2024-05-30"
  }
  

도서를 대출 기록에 추가.

 

7. 도서 반납 (Return a Book)

• 메서드: PATCH
• URI: /loanrecords/{id}
• 설명: 특정 대출 기록을 갱신하여 반납 처리.

 

8. 대출 기록 조회 (Get Loan Records)

• 메서드: GET
• URI: /loanrecords
• 필터링: 특정 사용자의 대출 기록만 조회.
  • URI: /loanrecords?userId={id}

 

RESTful 설계의 핵심

1. 자원의 명확한 URI:
   • /books, /loanrecords와 같은 엔드포인트는 자원을 나타냄.
2. HTTP 메서드의 올바른 사용:
   • CRUD 작업에 맞는 메서드 사용.
3. API 문서화:
   • 백엔드에서 제공하는 API 문서를 통해 클라이언트와 원활히 소통.