HTTP API란?
HTTP란?
HTTP는 위에서 알아보았는데 간단하게 요약하자면 HyperText Transfer Protocol의 약자로 서버 간에 데이터를 주고받을 때 사용하는 통신 규칙입니다.
그러면 API란 무엇일까요?
Application Programming Interface의 약자로 응용 프로그램에서 사용할 수 있도록 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻합니다
인터페이스(Interface)란?
인터페이스는 한글로 번역하면 "상호 작용" 이라는 의미이며 어떤 기계간의 장치끼리 정보를 교환하기 위한 수단이나 방법을 의미합니다.
결국 API란 응용 프로그램들이 서로 정보(데이터)를 주고받으며 상호작용하는 것을 도와주는 매개체로 볼 수 있습니다.
HTTP API란?
HTTP 메소드를 사용하여 클라이언트와 서버가 정보를 주고받으면 상호작용하는 것을 도와주는 매개체
HTTP method란?
클라이언트가 서버에 요청을 할 때 서버가 수행해야 할 동작을 지정합니다.
HTTP method 종류
주요 메서드
GET : 리소스 조회
POST : 요청 데이터 처리, 주로 등록에 사용
PUT : 리소스를 대체, 해당 리소스가 없으면 생성
PATCH : 리소스 부분 변경
DELETE : 리소스 삭제
기타 메서드
HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
OPTIONS : 대상 리소스에 대한 통신 가능 옵션을 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정
TRACE : 대상 리소스에 대한 경로에 따라 메시지 루프백 테스트를 수행
GET
리소스 조회
서버에 전달하고 싶은 데이터는 query를 통해서 전달
query가 아닌 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음
클라이언트에서 아래의 HTTP 메시지를 보낸다고 가정하겠습니다
GET /members/100 HTTP/1.1
Host: localhost:8080
서버는 HTTP 메시지를 받고 HTTP method는 GET, query로는 100번째 회원으로 해석하여 100번째 회원의 정보를 제공합니다.
서버는 회원의 정보를 응답 메시지에 담아서 보내게 됩니다.
POST
클라이언트가 서버에게 메시지 바디를 통해 요청 데이터를 전달하고 서버는 요청 데이터를 처리합니다.
주로 신규 데이터 등록에 사용됩니다(하지만 새로운 리소스가 생성되지 않는 경우도 있습니다.)
조회 데이터를 넘기고 싶은데 메시지 바디를 통해 데이터를 전달하기 때문에 GET 메서드를 사용하기 어렵다면 POST를 통해 사용할 수 있습니다. (GET은 query를 통해서 전달하기 때문에)
클라이언트에서 아래의 HTTP 메시지를 보낸다고 가정하겠습니다
POST /members HTTP/1.1
Content-Type: application/json
{
"username": "young",
"age": 20
}
서버는 HTTP 메시지를 받고 HTTP method는 POST, 메시지 바디로는 회원의 정보로 해석하여 새로운 회원 정보를 저장하게 됩니다.
이후에 서버는 회원이 잘 생성되었다는 정보를 응답 메시지에 담아서 보내게 됩니다.
PUT
리소스를 대체, 해당 리소스가 없으면 생성합니다.
쉽게 이야기하면 덮어씁니다.
클라이언트가 리소스 위치를 알고 URI를 지정합니다. ( POST와 차이점)
POST : POST /members HTTP/1.1
PUT : PUT /members/100 HTTP/1.1
PATCH
리소스 부분 변경
서버 쪽 데이터 /members/100이 아래와 같다고 가정해보겠습니다.
{
"username": "young",
"age": 20
}
클라이언트에서 아래와 같은 HTTP 메시지를 보냈다고 가정하겠습니다.
PACTH /members/100 HTTP/1.1
Content-Type: application/json
{
"age": 50
}
그렇게 되면 username은 변경되지 않고 age 부분만 20에서 50으로 변경됩니다.
DELETE
리소스 삭제
클라이언트에서 아래와 같은 HTTP 메시지를 보냈다고 가정하겠습니다.
DELETE /members/100 HTTP/1.1
Host: localhost:8080
서버는 HTTP 메시지를 받고 해석하여 100번째 회원정보를 지운다고 해석하고 데이터를 삭제하게 됩니다.
HTTP method의 속성
안전(Safe)
호출해도 리소스를 변경하지 않습니다.
GET, HEAD 등 조회하는 역할을 하는 method는 안전하고 DELETE, POST, PUT 등 변경이 일어나는 경우는 안전하지 않습니다.
멱등(Idempotent)
"멱등"이란 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미하는 수학용어라고 합니다.
여기서의 멱등은 한 번 호출하든 두 번 호출하든, N번 호출하든 결과가 똑같다는 것을 의미합니다.
GET, PUT, DELETE의 경우는 여러 번 같은 요청을 해도 결과가 똑같지만 POST의 경우에는 두 번 호출하면 같은 결제가 중복하여 발생하는 등 결과가 다를 수 있습니다.
서버가 TIMEOUT 등으로 정상적으로 응답을 주지 못하였을 때, 클라이언트가 같은 요청을 다시 해도 되는가의 판단 근거로 활용할 수 있습니다.
캐시 가능(Cacheable)
응답 결과 리소스를 캐시해서 사용해도 되는가?
GET, HEAD, POST, PATCH가 캐시로 가능하지만 실제로 GET, HEAD 정도만 캐시로 사용합니다.
POST, PATCH는 본문 내용까지 캐시 키로 고려해야 하기 때문에 구현하기에 어려움이 있습니다.
마지막으로 클라이언트에서 서버로 데이터 전송을 하는 예제를 알아본 뒤 실제 HTTP API를 설계하여 보겠습니다.
클라이언트에서 서버로 데이터 전송
데이터 전송 방법 2가지
1. 쿼리 파라미터를 통한 데이터 전송
GET 메소드를 사용하며 주로 검색에 사용됩니다.
2. 메시지 바디를 통한 데이터 전송
POST, PUT, PATCH 메소드를 사용하며 회원 가입, 상품 주문, 리소스 등록, 리소스 변경에 사용됩니다.
데이터가 전송되는 상황 4가지
1. 정적 데이터 조회(GET)
이미지, 정적 텍스트 문서
쿼리 파라미터는 사용하지 않고 리소스 경로로 조회할 수 있습니다.
보통 홈페이지에 접속하게 되면 아무것도 하지 않아도 홈페이지에 필요한 텍스트와 이미지를 불러오게 됩니다.
HTTP 메시지는 아래와 같다고 가정하겠습니다.
GET /static/star.jpg HTTP/1.1
Host: localhost:8080
서버는 이미지 파일을 요청하는 것으로 해석하고 클라이언트에게 이미지를 보내주게 됩니다.
2. 동적 데이터 조회(GET)
쿼리 파라미터를 사용하며 이를 기반으로 정렬 필터하여 결과 데이터를 동적으로 생성합니다.
주로 검색에 사용되며 조회 조건을 줄여주는것을 필터, 조회 결과를 정렬하는 것을 정렬이라고 하여 정렬 필터라고 합니다.
보통 홈페이지에서 우리가 무언가 요청하였을 때 발생합니다.
HTTP 메시지를 아래와 같다고 가정하겠습니다
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
서버는 쿼리 파라미터를 해석하여 hello에 대한 검색 결과를 클라이언트에게 전송하게 됩니다.
3. HTML Form 데이터 전송(GET, POST)
HTML의 Form 태그를 사용하여 데이터를 전송하는 방법입니다.
HTML FORM은 GET, POST만 지원하기 때문에 삭제, 삽입에 대해 PUT, DELETE를 사용할 수 없는 제약이 있습니다.
이를 해결하기 위해 /new, /edit, /delete 같은 동사로 된 리소스 경로를 사용하고 이를 컨트롤 URI라고 합니다.
전송 버튼을 누르면 아래와 같은 HTTP 메시지가 생성됩니다.
POST /save HTTP/1.1(start-line)
Host: localhost:8080(header)
Content-Type : application/x-www-form-urlencoded
(공백)(empty line)
username=kim&age=20(message-body)
이때 message-body부분은 쿼리 파라미터와 비슷한 형식을 가집니다.
만약 여기서 POST메서드 대신에 GET메서드를 사용하고 action="/save"가 아닌 "/members"를 사용한다면
아래와 같은 HTTP 메시지가 생성됩니다.
GET /members?username=kim&age=20 HTTP/1.1
Host: localhost:8080
POST에서는 message-body부분에 사용된 부분(username=kim&age=20)이 GET에서는 쿼리 파라미터로 올라가는 것을 알 수 있습니다.
Content-Type은 application/x-www-form-urlencoded가 기본값이며 multipart/form-data로 설정하면 다른 종류의 여러 파일과 폼의 내용을 함께 전송할 수 있습니다.
4. HTTP API 데이터 전송(GET, POST, PUT, PATCH, DELETE 등)
HTML Form을 사용하지 않는 거의 모든 상황
앱, 웹클라이언트에서 사용하며 서버끼리 통신할 때 많이 사용합니다.
클라이언트의 라이브러리를 통해 json 형식의 데이터를 넘기고 싶다면 아래와 같은 HTTP 메시지를 사용합니다.
POST /members HTTP/1.1
Content-Type: application/json
{
"username": "young",
"age": 20
}
Content-Type은 application/json을 주로 사용(사실상 표준)
그러면 이제 실제 HTTP API를 설계해보겠습니다.
그러면 회원 정보 관리 HTTP API URI를 만드려면 어떻게 해야 할까요?
뭔가 의미 있는 이름을 짓기 위해 노력하며 URI를 만들어 보겠습니다
- 회원 목록 조회 /read-member-list
- 회원 조회 /read-member-by-id
- 회원 등록 /create-member
- 회원 수정 /update-member
- 회원 삭제 /delete-member
그러면 이것이 좋은 URI 설계일까요?
가장 중요한 것은 리소스를 식별해야 합니다.
리소스란 회원을 등록하고 수정, 조회하는 것이 리소스가 아니며 회원이라는 개념 자체가 리소스입니다.
즉, 회원이라는 리소스만 식별해야 합니다.
그러면 다시 설계해 보겠습니다
- 회원 목록 조회 /members
- 회원 조회 /members/{id}
- 회원 등록 /members/{id}
- 회원 수정 /members/{id}
- 회원 삭제 /members/{id}
어떤 문제가 보이시나요?
조회, 등록, 수정, 삭제를 어떻게 구분할 수 있을까요?
URI는 리소스만 식별하고 이 리소스가 하는 행위를 분리합니다.
조회, 등록, 삭제, 변경하는 행위는 HTTP method를 활용하여 구분할 수 있습니다.
따라서 위에서 정리했던 HTTP method를 적용해 보겠습니다
- 회원 목록 조회 GET /members
- 회원 조회 GET /members/{id}
- 회원 등록 POST /members
- 회원 수정 PATCH, PUT, POST /members/{id}
- 회원 삭제 DELETE /members/{id}
출처
https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard
https://steemit.com/kr/@yahweh87/it-api
https://jaejong.tistory.com/40
https://ko.wikipedia.org/wiki/%EB%A9%B1%EB%93%B1%EB%B2%95%EC%B9%99