Web Back-end/Spring boot

REST API

ji.o.n.e 2021. 1. 16. 03:12

API (Application Programming Interface)

  • 응용 프로그램이 서로 통신할 수 있도록하는 일련의 규칙
  • 개발자는 서버에 API를 만들어 클라이언트와 대화할 수 있음

REST (Representational State Transfer)

  • 분산 네트워크 프로그래밍의 아키텍처 스타일
  • REST는 API의 구조(모양) 중 하나
  • 검색창에 입력하여 전송하는 것이 request, 검색된 결과를 서버에서 보내주는 것이 response

Request

4가지로 구성

  • The endpoint
  • The method
  • The headers
  • The data (or body)

엔드 포인트 (The endpoint)

  • 요청한 url
root-endpoint/?
  • root-endpoint는 클라이언트가 요청한 API의 시작점
  • 네이버 API의 경우 https://openapi.naver.com이 root-endpoint
  • 뒤의 ?는 path. path는 요청한 리소스를 결정해줌
  • https://openapi.naver.com/v1/search/blog와 같이 path를 붙일 수 있음. 블로그 검색을 호출한다는 의미
  • 사용가능한 path에 대해서는 API 문서 확인
  • path에 값(변수)를 대입하거나 query string(parameter)를 이용하기도 함
/user/:username/friend

이러한 path의 경우 :username에 결과를 원하는 사용자 이름을 대입하여 요청을 보내야 함
query string은 기본적으로 ?로 시작해 &로 구분하여 parameter를 이어감

/v1/search/book.xml?query=%EC%A3%BC%EC%8B%9D&display=10&start=1

위의 query string은 3개의 parameter가 있음. query는 검색하고자 하는 문자열, display는 검색 결과 갯수 지정, start는 검색위치로 부터 갯수

 

Method

  • GET : 서버로부터 정보를 가져올 때 사용 (Read)
  • POST : 리소스를 생성할 때 사용 (Create)
  • PUT : 리소스를 수정 (Update)
  • PATCH
  • DELETE : 리소스 제거 (Delete)

Get은 기본적으로 요청에 대해 같은 응답. 그러나 POST는 같은 응답 보장 안함

브라우저에서 GET 방식으로 요청한 후 뒤로가기 해도 아무 변화가 없지만 POST일 떄 뒤로가기 클릭하면 '양식 다시 제출 확인' 문구 뜸

 

Headers

  • Header는 서버와 클라이언트 모두에게 정보 제공해줌
  • 예를 들어 body에 담겨 있는 Content-Type이나 인증 정보 Authorization 등이 담겨있음
  • 클라이언트에서 헤더 정보를 먼저 읽을 수 있으므로 본문 내용을 읽을 필요가 없어 통신 효율이 좋음

Data

  • body나 message로 불리기도 함
  • 서버에 요청하기 위한 데이터 담겨 있음
  • GET 메소드의 경우에는 body가 없지만 POST의 경우 요청이 body가 되므로 url을 직접 호출할 수 있음

REST

REST 특징

  • 클라이언트/서버: 클라이언트와 서버가 서로 독립적이어야하고, 서로 의존성 때문에 확장에 문제 되는 일이 없어야 함
  • 상태 없음: 서버는 클라이언트의 상태를 기억할 필요가 없다
  • Layered Architecture: 서버와 클라이언트 사이에 다계층 형태로 레이어를 추가, 수정, 삭제 등 확장성이 있어야 함
  • Cache: 캐시를 갖고 있을 경우 클라이언트가 이를 통해 응답을 재사용하여 서버의 부하를 낮출 수 있음
  • Code On Demand: 요청이 오면 코드를 준다는말 그대로 클라이언트에서 서버를 동작시켜 원하는 기능 수행하도록 함
  • 통합 인터페이스: 서버와 클라이언트 간의 상호작용은 일관된 인터페이스들 위에서 이뤄져야 함

REST 인터페이스 규칙

통합 인터페이스를 위한 4가지 규칙

  • 리소스 식별: url과 같은 고유 식별자를 통해 구분
  • 표현을 통한 리소스 처리: JSON, XML, HTML과 다양한 컨텐츠가 있어도 데이터 변경 안됨
  • 자기 묘사 메시지: HTTP Header에 데이터에 대한 설명 나타내는 정보 담을 수 있음
  • 애플리케이션 상태에 대한 하이퍼미디어: 단순 데이터만 전달하지 않고, 링크 정보까지 포함하면 웹에 좀 더 친숙한 API가 됨

위의 사항들을 준수한 경우 RESTful하다고 함. RESTful한 API를 REST API라고 함.

저작자표시 (새창열림)