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 : 서버 에러
'네트워크' 카테고리의 다른 글
게임 네트워크 (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 |