1. api 란 ?
일단 api의 개념부터..
Application Programming Interface 한 프로그램에서 다른 프로그램으로 데이터를 주고 받기 위한 방법
ex) 메뉴판 : 손님↔가게 유저와 서버가 주고 받기 위한 방법
- api가 가져와할 내용
- 요청방식이 들어가야 한다(method) (get 요청) ex) 데이터를 요청할지 , 보내달라고 할지
- 무슨 자료 요청할지 (enapoint) ex) 어떤 데이터를 요청할 것인가 웹툰? 댓글? 뉴스?
- 파라미터 / 자료요청에 필요한 추가 정보 ex) 내 아이디, 이름 , 웹툰 몇 화
- public / private / partner API : public API (누구나 사용가능한 공인 API) , private API (사내에서 몰래 API) , partner API (미리 정해둔 유저만 쓰는 API)
- 모든 프로그램은 API 를 가질 수 있다운영체제 : windows api ( 윈도우가 제공하는 기능 사용가능) , datavase 관리 프로그램 api (DB와 관련된 기능들 사용가능)
2.1 RestFul API 란?
서버와 클라이언트과 통신을 하기 위한 규약(Rest) → (이 것을 rest하게 api를 설계하면 효율적으로 개발을 할 수 있다)
- Re REpresentational : 표현
- s State : 상태
- t Transter : 전송
해석 : "자원의 표현을 가지고 상태를 전달한다."
REST의 정의 : 분산 시스템 설계를 위한 아키텍쳐 (=구성) 스타일 / 네트워크 아키텍쳐 원리 모음/ 제약 조건의 원리 / 사이트 구성 원리
Rest : “사이트 구성 원리 “ , Restful : “Rest한” , Restful API : “Rest 한 API”
해석: 사이트 구성 원리를 준수하는 API
예시 1. GET youtube.com/feed/subscriptions 여기서 자원은 - 구독한 유튜버들의 영상들 이고 , 상태는 - get
2.2 왜 Restful API 를 사용해야 할까?
GET /
GET /sport/soccer 스포츠 안에서 축구라는 종목을 요청한다.
DELETE /sport/soccer/players/11 스포츠라는 것 안에서 축구라는 종목을 하는 플레이어들중 11번을 삭제하라
-> 위 처럼 rest api 메시지를 읽는 것만으로도 메시지가 의도하는 바를 명확하게 파악
-> 기본적으로 HTTP 프로토콜을 사용해서 서버와 클라이언트가 요청하고 응답을 처리한다.
-> HTTP 인프라를 그대로 사용하기 때문에, REST API 사용을 위한 별도의 인프라 구축이 필요없다. 그래서 우리는 restful api 사용
결론
Restful API 에서는 클라이언트는 단순히 리소스를 요청하면 서버는 해당 리소스를 응답해주기만 하면 된다.
ex) GET /sport/soccer/player → 서버 입장에서는 player라는 정보를 전달해주기만 하면 된다.
—> 결론 : 클라이언트와 서버가 독립적으로 운영이 가능! restful api를 사용해야 하는 이유!
2.3 구현 방법 (rest는 자원의 표현을 가지고 상태를 전달한다. )
자원(Resource) : URI에 명시 - /feed/subscriptions
표현(Representational) : Header로 전달 - text/html, image/gif , text/* (여기서 *은 text의 모든 타입을 일컫는다)
상태(State) : HTTP Method - GET, POST, PUT, DELETE
→ subscription은 클라이언트가 전달하는 데이터가 아니라 subscription에 메소드를 띄웠을 때 클라이언트가 전달받고자 하는 데이터를 헤더로 명시한다. 이것을 rest에서 ‘표현’이라고 얘기한다.
- 자원 (Resouce) : 모든 URI는 자원으로 나타낸다.
GET /sports/soccer/show
GET /sports/soccer/players/11/delete
→ 축구라는 것을 보여줌/ 플레이어 11번을 삭제함 —> 하지만 rest 설계 목적과는 다름
GET /sports/soccer
DELETE /sports/soccer/players/11
→ 더 명확하기 위해선 리소스를 자원으로 나타내야 한다! : URI에는 동사가 들어가선 안됌 무조건 자원(명사)가 들어가야 한다.
- 상태(State) : 모든 동작은 메소드로 나타낸다(상태=동사)
GET /sports/soccer → soccer를 보여주라
DELETE /sports/soccer/players/11 → 11을 지워주라
- PUT (수정) /waters/:삼다수 (어떻게 수정할지는 body를 통해 보냄)
- POST (생성) /waters
- DELETE (삭제) /waters/:삼다수
- GET (조회) /waters
- 표현 (Representational) : 리소스의 응답 타입은 Header로 나타낸다.
GET /chaanel/best_vis → 클라이언트 “JPG 확장자의 프로필 사진만 응답해주세요” (같은 메소드에 같은 경로인데 사진만 받고싶음)
Content-Type: text/html; charset=utf-8 //내가 전달하는 데이터가 html이라는 텍스트며 chareset은 utf-8이다.
→ 클라이언트가 전달하는 데이터의 타입 “요청하는 데이터의 타입” : 헤더로 받고 싶은 응답 타입을 명시해 줄 수 있다.
Accept : image/jpg
Accept: text/html, image/png //여러개 명시 가능
→ 클라이언트가 “응답받고 싶어 하는 데이터의 타입” : Accept 라는 헤더로 명시할 수 있다.
-> 어떤 응답을 받을지 모를 때 브라우저가 자동으로 설정해서 보내는 Accept를 사용하면 됨
Restful API 설계 원칙
- Uniform Interface (일관된 인터페이스)
- stateless (무상태성)
- cacheable(캐시 가능)
- code on demand
- layered system(계층형 시스템)
- client/serer
→ 이미 나머지는 원칙이 적용되어 있어 인터페이스만 rest하게 설계하면 된다.
2.4 Http 메소드 9가지
- GET : uri 형식으로 웹 서버 측 리소스(데이터)를 요청 , 이때 요청 받은 uri의 정보를 검색해 응답한다.
- HEAD: 메세지 헤더(내부 문서 정보) 취득
- GET방식과 유사, 응답에 바디가 없고 응답코드와 HEAD만 응답한다, 웹서버 정보 확인, 버전확인, 최종 수정일 등 조회시 사용
- POST : 내용 전송( 파일 전송 가능), 요청된 자원을 생성(create)한다.
- PUT : 내용 갱신 위주 (파일 전송 가능)
- 요청된 자원을 수정(update)한다, 모든 데이터를 수정할 때 사용한다. EX) 삼다수와 관련된 모든 데이터를 바꾸고 싶을 때
- PATCH : PUT 과 유사, 자원(데이터)의 일부를 교체하기 위해 사용한다. EX) 삼다수의 일부(예를 들어 이름)만 바꾸고 싶을 때
- DELETE : 요청된 자원을 삭제(delete)한다.
- CONNECT :요청된 자원에 대해 양방향 연결을 시작한다는 의미, 주로 웹 서버에 프록시 기능을 요청할 때 사용한다.
- OPTION : 목표 리소스와의 통신 옵션을 설명하기 위해 사용, 시스템에서 지원되는 메소드 종류 확인할 수 있다.
- TRACE : 클라이언트로부터 Request Packet의 변조 가능성이 있는데, 이때 서버에 도달한 최종 packet의 request packet볼 수 있다,
- 요청을 보낸 곳에 어떤 요청이 가공되어 있는 지 등을 조사할 수 있다.