웹 API
REST API(Representational State Transfer)
REST API는 자원을 주소로 구분하고 일관된 규칙으로 조회·변경하도록 설계한 API입니다.
쉬운 설명
스터디 목록을 조회하거나 신청 정보를 저장하는 API 문서를 읽을 때 REST API라는 말을 만날 수 있어요. 웹에서는 보통 URL로 대상을 나타내고 GET·POST 같은 HTTP 메서드로 요청의 의미를 구분해요. 같은 주소라도 메서드가 다르면 조회와 생성처럼 다른 일을 할 수 있어요. 정확한 주소와 요청 형식은 해당 API 문서를 따라야 해요.
이런 상황에서 만나요
“신청 목록은 GET /applications, 새 신청은 POST /applications로 처리하세요”라는 안내를 받았다고 해 볼게요. 먼저 대상 주소와 요청 목적을 함께 읽어요.
같은 주소라도 요청의 목적을 구분해요
GET /applications
POST /applications
{"studyId":"ai-study"}201 Created
{"id":"application-example"}- 1문서가 정한 목록을 조회하는 요청 예시예요.
- 2새 신청을 만들기 위해 JSON 본문을 보내는 예시예요.
- 3처리 결과와 새 신청의 식별자를 응답으로 받는 예시예요.
새 신청을 만들 때는 문서가 요구하는 본문과 인증 정보를 보내고 응답 상태를 확인해요. 아래 경로와 응답은 설명용 예시라 실제 서비스의 명세와 같다고 가정하지 않아요.
헷갈리기 쉬운 점
JSON을 주고받으면 모두 REST API인가요?
아니에요. JSON은 데이터를 표현하는 형식이고 REST는 API의 구조와 통신 규칙에 관한 설계 원칙이에요. JSON을 쓰지 않는 REST API도 있을 수 있고, JSON을 쓰면서 다른 설계 방식을 따를 수도 있어요.
데이터를 변경하는 요청은 대상과 권한을 확인해요. 주소를 알고 있다는 것만으로 접근 권한이 생기지 않아요. 실패한 생성 요청을 재시도할 때 중복 신청이 만들어질 수 있는지도 API의 동작을 확인해야 해요.
왜 알아야 할까요?
AI가 만든 프론트엔드와 백엔드의 주소·메서드·본문 형식이 맞는지 대조할 수 있어요. 조회와 저장을 구분해서 오류를 설명하거나 API 문서를 읽을 수 있어요.
조금 더 자세히
REST는 Representational State Transfer의 줄임말이고 API는 Application Programming Interface의 줄임말입니다. REST에는 클라이언트·서버 분리, 무상태 통신, 일관된 인터페이스 등 여러 설계 제약이 있습니다. GET·POST와 URL만 사용한다고 모든 REST 제약을 충족하는 것은 아닙니다.
무상태 통신은 서버에 데이터를 저장하지 않는다는 뜻이 아닙니다. 각 요청을 이해하는 데 필요한 정보를 그 요청에 포함하도록 하는 원칙입니다. 실무에서 REST API라는 이름은 넓게 쓰이므로 실제 사용법은 각 서비스의 명세를 확인합니다.
직접 사용할 때 확인해 보세요
- 주소와 HTTP 메서드를 함께 읽는다
- 본문 형식·인증·응답 상태를 문서와 대조한다
- 변경 요청과 재시도의 영향을 확인한다
관계 지도
