API
application programming interface.
서버-서버, 프로그램-프로그램, 송-수신자 등등의 두 매개체가 약속된 형식으로 데이터를 주고받을 수 있도록 프로그래밍된 컴포넌트, 매개체
http 요청을 통해 정보를 주고받는 API -> HTTP API 라고 함
아래와 같은 HTTP API가 있다고 하자. (URI에서 프로토콜, 도메인은 생략)
| 구분 | URI | 메소드 | 메세지 바디 예시 |
|---|---|---|---|
| 게시글 목록 | /hello | POST | {keyword: "검색키워드"} |
| 게시글 상세 | /world | POST | {id: 1} |
| 게시글 생성 | /nice | POST | {title: "", content: ""} |
| 게시글 수정 | /tomeet | POST | {id: 1, title: "수정 제목", content: "수정 내용"} |
| 게시글 삭제 | /you | POST | {id: 1} |
기능 동작은 정상적으로 하겠지만, URI와 메소드만 보고 각각 어떤 기능을 하는지 한눈에 파악하기 어렵다.
이를 아래와 같이 개선해보자.
| 구분 | URI | 메소드 | 메세지 바디 예시 |
|---|---|---|---|
| 게시글 목록 | /article/list | POST | {keyword: "검색키워드"} |
| 게시글 상세 | /article/detail | POST | {id: 1} |
| 게시글 생성 | /article/create | POST | {title: "", content: ""} |
| 게시글 수정 | /article/update | POST | {id: 1, title: "수정 제목", content: "수정 내용"} |
| 게시글 삭제 | /article/delete | POST | {id: 1} |
URI를 통해 각각 어떤 기능을 하는지는 명확해졌으나, 그 길이가 길어지고 행위와 행위에 대한 자원이 URI에 혼재되어 있다. 이를 명확히 구분할 순 없을까?
REST API
| 구분 | URI | 메소드 | 메세지 바디 예시 |
|---|---|---|---|
| 게시글 목록 | /articles?keyword=검색키워드 | GET | |
| 게시글 상세 | /articles/1 | GET | |
| 게시글 생성 | /articles | POST | {title: "", content: ""} |
| 게시글 수정 | /articles/1 | PUT/PATCH | {title: "수정 제목", content: "수정 내용"} |
| 게시글 삭제 | /articles/1 | DELETE |
위 예시에서는 URI에 목적 자원이 명시되어있고, 메소드를 통해 자원에 대한 행위를 명확하게 파악할 수 있다.
이렇듯 REST API는 API를 설계할 때 개발자들 사이에서 흔히 사용되는 어떤 설계의 틀이며, 누구든 각 요청의 의미를 쉽게 파악할 수 있도록 설계된 API를 말한다.
"Representational State Transfer”
Study&Work&Log