Restful Web Service

Web Servcie?

웹 서비스는 클라이언트에 대한 응답으로 HTML이 아닌 데이터 자체를 반환하는 Application.

• 웹 서비스와 Client는 HTTP로 통신한다. 웹 서비스는 HTML이 아닌 데이터를 반환.

REST?

REST 'REpresentational State Transfer'의 줄임말. 웹 서비스를 만들 때 적용하는 가이드라인

RESTful API 설계 원칙

RESTful API는 명확하고 직관적인 설계를 통해 유지보수성과 확장성을 높입니다. 위의 7가지 원칙을 잘 따르면 효율적이고 표준화된 API 구축 가능

1) URL 리소스 식별

• 설명: 리소스를 명확하게 식별하기 위해 URL 구조를 설계.
• 원칙:
  • 리소스를 명사로 표현 (예: /users, /orders).
  • 계층적 관계를 URL로 나타냄 (예: /users/{userId}/orders).
  • 리소스를 조작하는 동작은 HTTP 메소드를 사용.

2) HTTP 메소드로 리소스 조직

• 설명: CRUD 작업을 HTTP 메소드로 매핑.
• HTTP 메소드 예시:
  • GET: 리소스 조회.
  • POST: 새로운 리소스 생성.
  • PUT: 리소스 전체 업데이트.
  • PATCH: 리소스 부분 업데이트.
  • DELETE: 리소스 삭제.

3) 응답 바디의 데이터 형식

• 설명: 클라이언트로 반환되는 데이터 형식을 JSON, XML 등으로 결정.
• 원칙:
  • 기본적으로 JSON 형식을 사용 (가독성과 범용성).
  • Content-Type 헤더를 사용해 데이터 형식 명시 (예: Content-Type: application/json).

Accpet 헤더 응답	XML형식의 응답

4) 요청 바디의 데이터 형식

• 설명: 클라이언트에서 서버로 전달하는 데이터의 형식 정의.
• 원칙:
  • 요청 데이터는 JSON 형식을 권장.
  • 서버는 클라이언트가 보낸 데이터 형식을 Content-Type 헤더로 확인.
  • 예:

    {
      "name": "John Doe",
      "email": "john.doe@example.com"
    }

5) 상태 코드 활용

• 설명: 서버의 응답 상태를 HTTP 상태 코드로 전달.
• 주요 상태 코드:
  • 1XX : 처리 중
  • 200 OK: 요청 성공.
  • 201 Created: 리소스 생성 성공.
  • 204 No Content: 처리 성공, 응답 본문 없음.
  • 400 Bad Request: 잘못된 요청.
  • 401 Unauthorized: 인증 실패.
  • 404 Not Found: 리소스 없음.
  • 500 Internal Server Error: 서버 내부 오류.

6) 헤더 활용

• 설명: 요청 및 응답 메타데이터 전달.
• 주요 헤더:
  • Content-Type: 요청/응답 데이터 형식 지정 (예: application/json).
  • Authorization: 인증 토큰 전달 (예: Bearer <token>).
  • Accept: 클라이언트가 원하는 응답 데이터 형식 지정.

7) 서버 측을 무상태로 만들기

• 설명: 서버가 클라이언트 상태를 저장하지 않도록 설계.
• 원칙:
  • 모든 요청은 필요한 모든 정보를 포함해야 함.
  • 세션 상태를 유지하지 않고, 인증은 매 요청마다 처리 (예: 토큰 기반 인증).

다음 포스팅은 스프링 MVC의 REST 지원에 대해 정리하겠습니다.