본문 바로가기

네트워크

RESTful API

API : "통신 약속"으로 네가 이렇게 말하면 내가 이렇게 해줄게라는 약속이다. (한쪽이 어떻게 요청을 보내면 되는지 그에 대해 다른 쪽은 어떻게 응답해야 하는지 마치 메뉴판 처럼 정해져 있는 것)

 

RESTful API : 다양한 통신 약속 중 하나

 

REST API가 하는 일

- Create : 새로운 정보를 생성

- Read : 특정 데이터를 읽기

- Update : 특정 데이터를 변경

- Delete : 특정 데이터를 삭제

 

HTTP를 조건을 구현하기 용이하여 현업에서 주로 사용함

 

형식

https :// api.domain.com/v1/data/1

HTTP    URI (api(api로 사용되고 있다는 명시(필수 아님)), 서버주소), 버전(필수 아님), 해당 데이터,해당 데이터 id)

 

그렇다면 똑같은 형식으로 다른 작업을 한다고 했을 때 구분하는 방법이 무엇인가?

HTTP 메소드로 구분한다.

- POST - Create

- GET - Read

- PUT - Update

- PATCH - Update

- DELETE - Delete

 

데이터를 보낼 때 

GET , DELETETE 는 편지 봉투에 보내지고, PUT, PATCH, POST 는 소포상자에 보내진다. 즉 GET,DELETE 보다 더 많은 내용을 보낼 수 있다.

 

RESTful API의 요청과 응답에는 구조화된 데이터 표현이 가능하면서도 가벼운 JSON이 많이 사용된다.

 

각 요청의 응답에, 가용한 다른 요청들의 정보를 포함시키는 것도 중요하다.

포함 시켰을 때 포함된 링크 정보들을 통해서 동료 개발자들은 API 문서들을 다 뒤져보지 않아도 다음에 어떤 요청을 보낼 수 있는지 살펴볼 수 있고, 이 부분의 API의 세부사항이 변경되더라도, 클라이언트에서 이 정보를 참조하게 만들면 클라이언트의 코드를 고칠 필요가 없다.

 

특성

RESTful API의 또 다른 특성은, "상태가 없는" 통신이다.

 

- 클라이언트의 상태 정보가 서버에 저장되지 말아야 한다는 것

(서버는 클라이언트에 대해 아무것도 기억하지 말아야 한다는 것이고, 때문에 클라이언트의 요청은 몇 번째 반복되든, 필요한 모든 내용을 포함하고 있어야한다.

- 클라이언트가 요청을 몇번을 보내도 같은 응답을 해줘야한다는 특성(멱등성)도 있다. 

- 캐싱

 

요청의 응답 코드

2XX : 성공

4XX : 클라이언트 에러 : URI가 잘못되었거나, 권한 외의 요청을 하는 등 

5XX : 서버 에러 

728x90

'네트워크' 카테고리의 다른 글

게임 네트워크  (1) 2025.05.31
Lockstep Server  (2) 2025.05.26
터널링(Tunneling)  (0) 2025.05.23
gRPC  (1) 2025.01.16
TCP, UDP 차이점  (0) 2024.04.19