HTTP API를 만들어 보자
일단 먼저, API란?
"API(Application Programming Interface, 응용 프로그램 인터페이스 )는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다." - 위키백과
쉽게 말해서 API는 레스토랑의 '점원'이다. 레스토랑에서 손님에게 주문 가능한(선택 가능한) 메뉴를 보여주고 손님이
고른 음식을 주방에 전달 후, 음식이 나오면 고객에게 전달 하는'점원'이 API입니다.
--> API는 손님(클라이언트)이 주문할 수 있게 메뉴(명령 목록)를 정리하고, 주문(명령)을 받으면 요리사(서버, 응용프로그램)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달합니다.
API는 프로그램들이 서로 상호작용하는 것을 도와주는 매개체로 볼 수 있습니다.
- 회원 정보 관리 API를 만들어 보아라
--> 이런 상황일 때 일단 첫 번째로 고려해야 하는 것들이 뭐가 있을까?
클라이언트를 위한 메뉴판 정리(클라이언트를 위한 명령어 정리)
- 회원 목록 조회
- 회원 조회
- 회원 등록
- 회원 수정
- 회원 삭제
등등 여러 가지 명령들이 있을 것이다.
이 명령들을 서버와 상호작용 시키기 위해 어떤 방식으로 처리해야 할까?
그러니까 점원이 손님이 시킨 음식(데이터)을 가지러 갈 때
그 음식이 어느 위치에 있는지, 어떤 음식인지(식별) 알려줘야 하지 않을까?
위치와 식별하면 아는 것이 있다.
바로 URI다.
- API URI 설계
식당에서 손님이 특정 음식을 시켰고, 이제 점원이 음식을 향해서 가고 있다. 하지만 엉뚱한 음식을 가지고 나온다면...
손님은 정말 답답하지 않겠는가?
즉 서버가 엉뚱한 자료(리소스, 데이터)를 가져다준다면 답답하지 않겠는가?
그렇다면 URI 설계에서 가장 중요한 것은 무엇일까?
주방에서 준비된 음식 식별 = 리소스, 데이터 식별이다.
이제 본론으로 돌아와서...
- 회원 정보 관리 API에서 리소스는 무엇일까?
- 회원을 등록하고 수정하고 조회하는 것이 리소스가 아니다!
- 회원이라는 개념 자체가 바로 리소스다!
그렇다면 이제 리소스를 어떻게 식별하는 게 좋을까?
- 회원을 등록하고 수정하고 조회하는 것은 모두 배제
- 회원이라는 리소스만 식별하면 된다 -- > 회원 리소스를 URI에 매핑
- 리소스와 행위를 분리
- URI는 리소스만 식별!
- 리소스와 해당 리소스를 대상으로 하는 행위를 분리
리소스 : 회원
행위 : 조회, 등록, 삭제, 변경
그렇다면 행위는 어떻게 구분하는 것인가?
바로 HTTP 메서드로 구분한다
HTTP 메서드
- HTTP 주요 메서드
- GET : 리소스 조회 ( 어떤 데이터가 있는지 알려줘 )
- POST : 요청 데이터 처리, 주로 등록에 사용 ( 데이터 담아서 보낼게 )
- PUT : 리소스를 대체, 해당 리소스 없으면 생성 ( 이 데이터로 대체해줘 )
- PATCH : 리소스 부분 변경 ( 특정 데이터를 변경해줘 )
- DELETE : 리소스 삭제 ( 데이터 삭제해줘 )
- HTTP 기타 메서드
- HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환
- OPTIONS : 대상 리소스에 대한 통신 가능 옵션(메서드)을 설명
- HTTP 주요 메서드 설명
1) GET
- 서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해서 전달
- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장하지 않음.
2) POST
- 메시지 바디를 통해 서버로 요청 데이터 전달
- 서버는 요청 데이터를 처리 ---> 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용
- POST는 요청 데이터를 어떻게 처리한다는 뜻일까?
1) HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공
EX) HTML FORM에 입력한 정보로 회원가입
2) 게시판, 뉴스그룹, 메일링 리스트, 블로그 또는 유사한 기사 그룹에 메시지 게시
EX) 게시판 글쓰기, 댓글 달기
3) 서버가 아직 식별하지 않은 새 리소스 생성
EX) 신규 주문 생성
4) 기존 자원에 데이터 추가
EX) 한 문서 끝에 내용 추가하기
--> 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 따로 정해야 함
(정해진 처리 방식이 없다)
* POST는 모든 것을 할 수 있다. 그러나 조회는 GET이 낫다.
3) PUT
- 리소스가 있으면 대체
- 리소스가 없으면 생성
- 쉽게 이야기해서 덮어버림
- 클라이언트가 리소스를 식별 ---> 클라이언트가 리소스 위치를 알고 URI 지정 (중요!) ---> POST와의 차이점.
4) PATCH
5) DELETE
참고:
본 포스팅에 있는 모든 자료는 김영한 님의 HTTP 웹 기본지식 강의의 자료들 입니다.
'웹 > http' 카테고리의 다른 글
김영한 님의 HTTP 웹 기본지식 강의/5.HTTP 상태코드 (0) | 2021.09.21 |
---|---|
김영한 님의 HTTP 웹 기본지식 강의/4.HTTP 메서드/HTTP 메서드의 속성 (0) | 2021.09.18 |
김영한 님의 HTTP 웹 기본지식 강의/3.모든것이 HTTP (0) | 2021.09.13 |
김영한 님의 HTTP 웹 기본지식 강의/2.URI와 웹 브라우저 요청 흐름 (2) | 2021.09.11 |
김영한 님의 HTTP 웹 기본지식 강의/1.인터넷 네트워크/DNS (0) | 2021.09.10 |