REST와 HTTP 메서드
2024. 12. 30. 19:17ㆍCS
REST(Representational State Transfer)는 웹에서 사용되는 API 설계 아키텍처 스타일이야.
간단히 말하면, 클라이언트와 서버가 자원을 요청하고 전달하는 방식을 정의한 거야.
REST의 핵심 원칙
- 자원의 표현 (Resource Representation)
- 자원은 URI(Uniform Resource Identifier)로 식별돼.
예: https://example.com/users/123 → 특정 유저 자원을 가리킴. - 자원은 JSON, XML, HTML 등 표현 형식으로 전달됨. 요즘은 JSON이 가장 많이 쓰여.
- 자원은 URI(Uniform Resource Identifier)로 식별돼.
- HTTP 메서드를 활용
- REST는 HTTP 메서드를 사용해서 자원에 대한 동작을 명확히 함.
- HTTP 주요 메서드:
- GET: 자원 조회
- POST: 자원 생성
- PUT: 자원 전체 수정
- PATCH: 자원 일부 수정
- DELETE: 자원 삭제
- 무상태성 (Statelessness)
- 서버는 클라이언트의 상태를 저장하지 않아.
모든 요청은 독립적이고, 필요한 정보는 요청에 포함돼야 해.
예: 인증 정보는 매번 요청에 포함해야 함.
- 서버는 클라이언트의 상태를 저장하지 않아.
- 계층적 구조 (Layered System)
- 클라이언트는 서버와 직접적으로 통신하는지, 프록시를 거치는지 몰라.
이런 구조는 확장성과 보안성을 높이는 데 도움을 줘.
- 클라이언트는 서버와 직접적으로 통신하는지, 프록시를 거치는지 몰라.
- 캐시 가능 (Cacheable)
- 응답 데이터는 캐싱될 수 있어야 해.
클라이언트는 응답에 포함된 캐시 관련 정보를 활용해 요청을 줄일 수 있어.
- 응답 데이터는 캐싱될 수 있어야 해.
REST API 설계의 좋은 예
- 자원의 경로는 명사를 사용하고 복수형으로 설계함.
- GET /users → 모든 사용자 조회
- GET /users/123 → ID가 123인 사용자 조회
- POST /users → 새로운 사용자 생성
- PUT /users/123 → ID가 123인 사용자 수정
- DELETE /users/123 → ID가 123인 사용자 삭제
- HTTP 상태 코드를 활용해 요청 결과를 표현함.
- 200 OK: 성공
- 201 Created: 생성 성공
- 400 Bad Request: 잘못된 요청
- 404 Not Found: 자원 없음
- 500 Internal Server Error: 서버 오류
REST의 장점과 단점
장점
- 표준 HTTP 프로토콜을 사용하므로, 범용적이고 언어 독립적이야.
- 구조가 단순하고 명확해서 이해하기 쉬워.
- 캐싱을 활용하면 성능 최적화 가능.
단점
- 요청마다 인증 정보를 보내야 해서 오버헤드가 있을 수 있어.
- 복잡한 트랜잭션 처리에는 적합하지 않을 수 있어.
- 무상태성 때문에 클라이언트가 더 많은 정보를 처리해야 할 때도 있어.
HTTP 메서드
- HTTP 메서드는 클라이언트가 서버에게 어떤 작업을 요청하는지 알려주는 역할을 해.
- HTTP(Hypertext Transfer Protocol)는 웹에서 클라이언트와 서버 간의 데이터 전송을 위한 규약이기 때문에, HTTP 메서드는 웹 서버와 클라이언트 간의 요청과 응답을 처리할 때 기본적으로 사용되는 방법이야.
- REST API에서는 주로 HTTP 메서드를 활용해서 자원(Resource)에 대해 다양한 작업을 수행하지.
- 그러나 HTTP 메서드는 REST 방식에만 제한된 것이 아니라 HTTP 통신을 사용하는 모든 상황에서 사용돼!
- 웹 페이지 로드 (웹 브라우징): 웹사이트를 방문할 때 대부분 GET 요청을 사용해서 페이지를 가져오지.
- 파일 업로드: 파일을 서버로 업로드할 때 POST 요청을 사용해서 데이터를 서버에 전송하지.
- API 요청: REST API는 HTTP 메서드를 사용하지만, SOAP, GraphQL 같은 다른 API 스타일에서도 HTTP 메서드를 사용할 수 있어.
주요 HTTP 메서드 정리
1. GET
- 자원을 조회할 때 사용해.
- 서버에서 데이터를 가져오지만, 데이터를 변경하지 않아.
- 예:서버는 ID가 123인 사용자 정보를 반환.
- 특징: 요청에 Body가 없음, 캐싱이 가능해서 성능 최적화에 유리함.
2. POST
- 새로운 자원을 생성할 때 사용해.
- 주로 클라이언트가 서버에 데이터를 전송하여 새로 추가함.
- 예:서버는 새로운 사용자 데이터를 저장하고, 생성된 자원의 ID를 반환할 수 있어.
- 특징: 요청에 Body를 포함, 같은 요청을 반복하면 자원이 중복 생성될 수 있어(idempotent하지 않음).
3. PUT
- 자원을 완전히 대체하거나 업데이트할 때 사용해.
- 자원의 전체를 수정하므로, 누락된 필드는 삭제될 수 있어.
- 예:ID가 123인 사용자의 정보를 완전히 대체.
- 특징: 요청에 Body를 포함, 같은 요청을 반복해도 결과가 같음(idempotent).
4. PATCH
- 자원의 일부만 수정할 때 사용해.
- PUT과 달리 전체가 아닌 일부 속성만 변경 가능.
- 예:ID가 123인 사용자의 이메일만 업데이트.
- 특징: PUT보다 효율적이며, 수정하려는 데이터만 전송.
5. DELETE
- 자원을 삭제할 때 사용해.
- 예:ID가 123인 사용자를 삭제.
- 특징: 요청에 Body를 포함하지 않음, 요청을 반복해도 결과는 같음(idempotent).
그 외 메서드 (잘 쓰이진 않지만 알아두면 좋아)
6. HEAD
- GET과 유사하지만, 응답 본문(Body)이 없음.
- 요청한 자원이 존재하는지 확인하거나, 메타데이터(헤더)만 필요할 때 사용.
- 예: 웹사이트 상태 체크.
7. OPTIONS
- 서버가 지원하는 HTTP 메서드 목록을 반환.
- API가 어떤 작업을 허용하는지 확인할 때 사용.
8. TRACE
- 요청이 서버에 도달했는지 추적할 때 사용.
- 보안 이슈 때문에 거의 사용되지 않아.
9. CONNECT
- 클라이언트와 서버 간의 터널링을 설정할 때 사용.
- 주로 HTTPS 연결을 위해 프록시 서버에서 사용.
RESTful API 설계에서 URI와 HTTP 메서드의 조합
RESTful API 설계에서는
URI를 사용해서 특정 자원을 식별하고,
HTTP 메서드를 통해 그 자원에 대해 어떤 작업을 할지 결정해.
RESTful API 설계에서는 HTTP 메서드와 URI를 조합해서 명확하고 직관적인 API를 만들 수 있어.
| 메서드 | URI | 설명 |
| GET | /users | 모든 사용자 조회 |
| GET | /users/123 | ID가 123인 특정 사용자 조회 |
| POST | /users | 새로운 사용자 생성 |
| PUT | /users/123 | ID가 123인 특정 사용자 전체 수정 |
| PATCH | /users/123 | ID가 123인 특정 사용자 일부 수정 |
| DELETE | /users/123 | ID가 123인 특정 사용자 삭제 |
참고: URI와 URL
- URI (Uniform Resource Identifier)
- URI는 자원의 고유 식별자야.
- URI는 자원을 식별할 수 있는 방법을 제공해. 자원이 어디에 있는지, 어떻게 접근할 수 있는지까지는 포함하지 않아.
- URL (Uniform Resource Locator)
- URL은 URI의 한 종류로, 자원의 위치와 접근 방법까지 포함해.
- 즉, URL은 자원의 위치(주소)와 그 자원에 접근하기 위한 방법(예: HTTP, FTP 등)을 포함한 URI야.
- 모든 URL은 URI이지만, 모든 URI가 URL은 아냐. URL은 URI의 구체적인 형태라고 생각하면 돼.
- 차이점
- URI는 자원의 식별자에 초점을 맞춰, "이 자원이 무엇인지" 알려줘.
- URL은 자원의 위치와 접근 방법까지 포함해서, "이 자원을 어떻게 찾을 수 있을지" 알려줘.
| URI: 고유 식별자 | URL: 위치와 접근 방법을 포함한 식별자 |
| /users/123 "ID가 123인 사용자"라는 자원을 식별하는 방법 |
https://example.com/users/123 "https" 프로토콜을 사용해, "example.com" 서버에서 "users/123" 자원에 접근하겠다 |
| /products/456 "제품 ID가 456인 제품"을 식별하는 방법 |
http://example.com/products/456 HTTP 프로토콜을 사용하여 "example.com" 서버에서 "456번 제품"에 접근하겠다 |
| /images/logo.png "logo.png"라는 이미지를 식별하는 방법 |
ftp://files.example.com/images/logo.png FTP 프로토콜을 사용해서 "files.example.com" 서버에서 "images/logo.png" 이미지를 다운로드하겠다 |