서버 이론 뿌시기 - HTTP API

지금까지 웹 통신, URI와 웹 통신의 흐름, HTTP에 관한 게시물을 작성했다.

 

이제 HTTP API를 한번 만들어 볼까 한다.

 

HTTP API란??

그래 HTTP는 인터넷 통신에서 사용하는 통신 규약이라는거 까지는 알았다.

그런데 API는 무엇일까?

 

영어를 하나하나 뜯어보면

Application Programming Interface이다.

 

우선 Interface란 서로 다른 두 시스템간 정보를 주고받는 경계면을 말한다.

 

이렇게만 말하면 어려울 것 같아서

한가지 예시를 들어보겠다.

 

식당이 하나 있다고 하자.

 

식당에 요리사와 손님만 있다면 어떨까??

 

손님은 요리를 주문하고 요리사는 요리를 만들어야 하는데 둘 사이를 이어줄 점원이 필요하게 된다.

 

이 점원이 정보 소통의 경계이자 다리인 역할을 하게되는 셈이다.

 

즉 API란 인터페이스에서 서버가 가지고 있는 리소스를 달라고 요청하는 역할을 한다.

 

지난번 게시물에서 서버에 리소스를 요청하는 과정을 설명한 적이 있다.

 

인터넷에 리소스를 요청하기 위해서는

ip, port, path, query가 필요하고 이것들을 URI(Uniform Resource Identifier)라고 했다.

 

클라이언트인 웹 브라우저는 서버에 URI에 요청을 보내게 된다.

URI 설계가 백엔드 개발자의 첫걸음이라고 할 수 있다.

 

백엔드 개발은 서버를 설계를 하는 일이고

백엔드 개발자라면 클라이언트 요청에 알맞은 리소스를 빠르고 에러없이 제공해야 한다.

 

요청이 들어오면 리소스를 에러 없이 전달해야 한다?

어??? 아까 점원이 생각나지 않는가?

요청의 소통구이자 문의 역할을 하는 것을 API라고 한다.

 

API를 URI형태로 나타나게 되고 요청의 목적지를 엔드 포인트라고 한다.

• https://www.google.com/search?q=hello&hl=ko

위 URI에서 /search?q=hello&hl=ko를 엔드포인트라고 하고

주로 Path + Parameter만을 가리킨다.

 

자, 그러면 API가 뭔지 알았으니까 직접 작성해보도록 하자.

 

API 작성

 

위와 같은 해당 요구 사항을 받았다고 하자.

 

위의 요청은 CRUD를 만들어야하는 요청이다.

 

API 설계를 할 때는 각 요청마다 문을 만들어야 한다.

 

• 회원 목록 조회/read-member-list
• 회원 조회/read-member-by-id
• 회원 등록/post-member
• 회원 수정/put-member
• 회원 삭제/delete-member

이렇게 위처럼 5개의 URI을 만들어 주면 되지 않을까??

 

그랬으면 너무 쉬웠겠지..

 

URI란 뭐였나??

 

Uniform Resource Identifier다.

가장 중요한게 리소스의 식별이다.

 

저기서 과연 생성 조회 수정 삭제가 리소스 일까?

 

그렇지 않다.

위의 요구사항에서 리소스는 회원이라는 개념밖에 없다.

 

따라서 URI는 다음과 같이 작성 될 수 있다.

• 회원 목록 조회/members
• 회원 조회/members/{id}
• 회원 등록/members/{id}
• 회원 수정/members/{id}
• 회원 삭제/members/{id}

따라서 위와 같이 만들어주면 된다.

 

응?? 그러면 저게 뭔지 어떻게 구분을 하나요??

 

방법이 다 있지 않겠나??

지금부터 어떻게 그걸 하는지 살펴볼거다.

 

HTTP 메서드

먼저 리소스를 구분하는 URI와 행위를 구분하는 HTTP 메서드로 분리를 한다.

GET, POST, PUT, DELETE 

 

HTTP 게시물에서 HTTP 메서드로 위 4가지를 배웠었다.

 

시작라인에서 맨 처음 오는게 HTTP메서드라고 했던게 기억이 날거다.

 

위 4가지 메서드들이 어떤 역할을 하는지 살펴보자.

 

HTTP 메서드 - GET,POST

 

GET(조회)의 특징

• GET은 알다시피 리소스를 조회하는 역할을 한다.
• 서버에 전달하고 싶은 데이터를 query에 담아서 전달하게 된다.
• 메세지 바디에 데이터를 넣는 경우는 거의 없다

자 /members/100이라는 query로 GET요청을 보낸다고 생각해보자.

 

서버의 /members/100에는 회원 정보가 들어가 있을거다.

 

서버는 해당 위치의 정보를 응답메세지에 담아서 전달해줄거다. 

 

POST(생성)의 특징

• 메세지 바디를 통해 서버로 요청 데이터를 전달한다.
• 전달된 데이터로 신규 리소스를 등록한다.

새로운 회원을 등록하는 URI를 달아준다고 해보자.

 

새로 등록하는 member에는 id가 할당 되지 않았을거다.

따라서 /members에 POST요청을 보내면 된다.

 

서버는 해당 요청을 받으면 새로운 멤버에 id=100을 할당하고

 

잘 등록되었다고 응답을 다시 보내게 된다.

 

POST와 GET의 차이??

그렇다면 POST와 GET의 차이는 무어일까?

 

아 당연히 POST는 생성이고 GET은 조회겠죠~

 

이렇게 생각하는 사람이 매우 많을거다.

 

그러나 그렇지 않다.

 

둘의 차이는 거의 없는데 사실상 메세지 바디를 가지냐 안가지냐 정도로 밖에 차이가 나지 않는다.

 

특정 데이터를 담아서 조회를 하기도 하기 때문에 조회에 POST를 사용하기도 한다.

 

그럼 데이터를 같이 넘기면 무조건 POST인가? 

 

그건 또 아니다. ㅋㅋ

 

parameter에 정보를 같이 넘길수도 있기 때문이다.

 

아니 그럼 도대체 두개 차이가 뭔데??

 

그건 바로 URI에 노출되면 안되는 정보를 넘길때 POST를 사용하게 된다.

 

GET요청으로 회원 정보를 보냈는데 id password가 다 URI에 노출되면

대참사가 발생할 수 있기 때문이다.

 

자 생성, 조회는 끝났다.

 

PUT(수정)의 특징

• 리소스를 대체한다.
• 리소스가 있으면 대체하고 없으면 생성한다.
• 쉽게 말해 아예 덮어 써버린다.

 

• 클라이언트가 리소스의 위치를 알고 URI를 지정한다.
• 이점이 POST와 다르다. 

리소스가 있는 경우에는 전달 받은 데이터로 해당 위치의 리소스를 변경한다.

 

리소스가 없는 경우에는 해당 위치에 리소스를 생성하게 된다.

 

주의 할점은 리소스를 완전히 대체한다는 거다.

 

자 위 사진처럼 데이터를 PUT한다면 어떨까??

 

주의-리소스를 완전히 대체한다!!

에서 볼 수 있듯이 username은 사라지고

/members/100의 위치에는 "age":50만 남게 될거다.

 

PATCH(수정)의 특징

PUT이 수정이라는거까지는 배웠는데

PATCH는 뭐에요??

 

PATCH 역시 수정이다.

 

PUT과 다른점이 존재하니 따로 쓰지 않을까?

 

PATCH는 완전히 대체하지 않고 수정하는 것을 말한다.

 

위에서 age에 해당하는 특성만을 수정하고 싶다고 해보자

 

만약 PUT을 사용한다면 name과 age모두 같이 수정해줘야 하지만

PATCH를 사용한다면 age만 고쳐주어도 리소스의 정보가 바뀌게 된다.

 

PUT과 PATCH의 차이점

PUT과 PATCH의 차이점은 완전히 대체한다와 일부분만 대체한다는 점이있다.

 

PUT과 PATCH를 구분해서 쓰는 집단도 있지만 그렇지 않는 집단이 사실상 대부분이다.

 

PUT을 주로 선호하는데

회원 정보를 담는 클래스가 바뀔 수 있기 때문이다.

 

위 사진처럼 id와 name만을 저장하던 Class에서

age까지 같이 저장하도록 업데이트 했다고 하자.

 

name을 추가할때는 PUT을 활용할 수 있지만

age를 추가한 필드에서 name을 변경하려 할때는 PATCH로 메서드를 수정해야하고

API의 메서드를 변경하는 작업은 쉽지 않기 때문에 유지비용이 올라가게 된다.

 

이런 점에서 주로 PUT과 PATCH 중 하나의 메서드만을 사용하는 경우가 많다.

 

DELETE는 해당 위치의 리소스를 지우는 역할을 한다.

 

HTTP 메서드 활용

클라이언트에서 서버로 데이터를 전달하는 방식은 크게 2가지가 있다.

 

query를 통한 데이터 전송

• GET
• 주로 검색어 정렬 필터

 

메세지 바디를 통한 데이터 전송

• POST, PUT, PATCH
• 회원 가입, 상품 주문, 리소스 등록, 리소스 변경등

 

클라이언트에서 서버로 데이터를 전송하는 4가지 상황

클라이언트가 서버로 데이터를 전송하는 방식은 총 4가지가 있다.

4가지 상황을 하나씩 뜯어가면서 분석해 보도록 하자.

 

정적 데이터 조회

• 이미지, 정적 텍스트 문서

동적데이터 조회

• 검색, 정렬 필터

HTML Form을 통한 데이터 전송

• 회원 가입, 상품 주문

HTTP API를 통한 데이터 전송

• 회원 가입, 상품 주문, 데이터 편경

 

정적 데이터 조회??

• 주로 이미지 정리나 정적 텍스트 문서를 조회할때의 상황이다.
• 조회를 할때 GET을 사용한다.
• 정적 데이터는 일반적으로 query없이 리소스 경로로 단순하게 조회가 가능하다.

 

동적 데이터 조회??

동적 데이터 조회란 쿼리 파라미터에 따라서

서버에 있는 해당 리소스 중 필터링을 거쳐 알맞은 결과를 생성하게 된다.

 

• 주로 검색, 게시판 목록 정렬할 때의 상황이다.
• 조회는 GET을 사용하고 쿼리 파라미터를 사용해 데이터를 전송한다.

 

HTML form으로 데이터 전송

• HTML의 form태그가 자동으로 HTTP 메세지를 만들어서 전송하는 방식이다.
• 웹 브라우저가 직접 요청 HTTP메세지를 생성한다.

 

HTTP API 데이터 전송

javascript로 직접 HTTP메세지를 만들어서 보내는 형식이다.

• 모든 HTTP메서드를 사용할 수 있다.

 

HTTP 상태 코드

HTTP 응답 메세지를 자세히 들여다보면 특이한 부분이 있을거다.

200 OK??

이게 뭐지??

 

200 OK는 응답의 상태를 알려주는 코드이다.

 

상태코드는 100~599까지 존재하는데

주로 몇개밖에 사용되지 않으니 알려주는 부분만 알면 된다.

 

1XX

거의 사용하지 않는다 ㅋㅋ

 

2XX

클라이언트의 요청을 성공적으로 처리했다는 걸 의미한다.

 

4XX

클라이 언트 요청에 잘못된 문법으로 서버가 요청을 수행할 수 없다는 걸 말한다.

오류의 원인이 클라이언트에 있는 셈이다.

잘 아는 404 에러 같은게 있다.

 

5XX

서버에 오류가 발생했다는 것을 의미한다.