RESTful API
- RESTful API(Representational State Transfer API)는 HTTP 프로토콜을 기반으로 자원을 주고받는 방식을 설계 원칙에 맞게 구현한 API
- REST 설계원칙을 반영하여 HTTP 표준 기반, 자원 중심 URI, 메서드 기반 행위, 일관된 인터페이스 등을 구현한 것
- REST 설계원칙은 밑에서 설명한다.
*http는 별개 포스트로 올릴계획이다.

1. REST의 기본 개념
- REST는 2000년 로이 필딩(Roy Fielding)의 박사 논문에서 제안된 아키텍처 스타일입니다.
- 웹의 기본 동작 원리(HTTP, URI, 무상태성 등)를 최대한 활용하여 간단하고 확장 가능한 네트워크 통신을 구현하는 것이 목적입니다.
- RESTful API는 REST 원칙을 준수하여 설계된 API를 의미합니다
2. RESTful API 설계 원칙
- Uniform Interface (일관된 인터페이스)
- URI는 자원을 나타내고, HTTP 메서드로 행위를 표현
- Stateless (무상태성)
- Cacheable (캐시 가능)
- Layered System (계층 구조)
- API 서버, 인증 서버, 데이터 서버를 계층화할 수 있음
- Client-Server 구조
- 클라이언트와 서버는 독립적으로 발전 가능
3.핵심 구성 요소
- 자원(Resource) : HTTP URI로 식별 (예: /users/1, /products/42)
- 행위(Verb) : HTTP 메서드로 표현 (GET, POST, PUT, DELETE 등)
- 표현(Representation) : 자원의 상태를 JSON, XML 등 특정 포맷으로 전달
4.HTTP 메서드
- GET : 조회
- POST : 생성
- PUT : (전체)수정
- DELETE : 삭제
- PATCH : (일부)수정
5.RESTful URI 설계 규칙
- 자원은 명사로 표현:
- 예를 들어, /users, /products 와 같이 자원을 나타내는 명사를 사용합니다.
- 행위는 HTTP 메소드로 표현:
- GET, POST, PUT, DELETE 와 같은 HTTP 메소드를 사용하여 자원에 대한 행위를 표현합니다.
- URI에 동사를 사용하지 않습니다.
- 계층적 구조:
- 자원 간의 관계를 계층적으로 표현합니다.
- 예를 들어, /users/123/orders는 123번 사용자의 주문 목록을 나타냅니다.
- 소문자 사용, 하이픈(-) 사용:
- 가독성을 위해 소문자를 사용하고, 단어 구분에는 하이픈을 사용합니다.
- 마지막 슬래시(/) 생략:
- URI 마지막에 슬래시를 사용하지 않는 것이 일반적입니다.
URL, URL 차이
RESTful API 설계에서 URI는 자원을 표현하고, URL은 해당 자원의 위치를 나타냅니다. URI는 자원 식별자 역할을 하며, URL은 자원의 위치를 가리키는 특정 유형의 URI입니다. 즉, 모든 URL은 URI에 포함되지만, 모든 URI가 URL인 것은 아니다.
1.URI
- Uniform Resource Identifier
- 자원의 식별자 (위치·이름 포함)
- URI의 하위 개념으로 URL과 URN이 있음
- abc@example.com (으로 위치정보없음)
2.URL
3.URI 범위 관계
├── URL (위치 기반 식별자)
└── URN (이름 기반 식별자, 위치 정보 없음)
구성 요소

- scheme : 통신 방식(프로토콜)을 결정한다. http, https를 사용함
- hosts : 도메인+port번호 or 퍼블릭IP+port번호
- url-path : 웹 서버에서 지정한 루트 디렉터리부터 시작하여 웹 페이지, 이미지, 동영상 등이 위치한 경로와 파일명을 나타낸다.
- query-String : 웹 서버에 보내는 추가적인 질문이다, 쿼리스트링
REST가 무슨 약자인지 알고 있기! 중요