REST API

REST : REpresentational State Transfer, 웹(HTTP)의 장점을 활용한 아키텍쳐
REST의 개념과 구성, RESTful하게 API를 설계하는 방법과 그 장점을 이해한다.

<REST API>

REST API | 👨🏻‍💻 Tech Interview

---

REST 메소드 4가지 설명

• GET : select, 정보를 조회
• POST : insert, 정보를 저장
• PUT/PATCH : update, 정보를 수정
• DELETE : delete, 정보를 삭제

 

POST , GET 차이는?

• GET
  • 서버로부터 정보를 조회하기 위해 설계된 메소드 
  • 요청 시 필요한 파라미터를 쿼리스트링으로 url 뒤에 노출시켜 전송 => 길이 제한이 있어 많은 양의 데이터를 보내기 어려움
  • 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있음 => js, css, 이미지 같은 정적 컨텐츠는 데이터 양이 크고 변경될 일이 적어 반복해서 동일한 요청을 보낼 필요 X (캐싱 처리 되므로)
  • Idempotent하다 => 서버에 동일한 요청을 여러 번 전송해도 동일한 응답이 돌아와야 함
• POST
  • 리소스를 생성 및 변경하기 위해 설계된 메소드 
  • 요청 시 필요한 파라미터(데이터)를 Body로 전송 => 대용량 데이터를 전송할 수 있음, url노출이 안되더라도 개발자 도구에 노출되기에 민감 데이터의 경우 반드시 암호화처리 후 전송해야 함!
  • Non-idempotent하다 => 서버에 동일한 요청을 여러 번 전송해도 응답은 항상 다를 수 있음

 

REST란?, RESTful하게 API를 디자인한다는 게 무슨 뜻?

• REST?
  • 자원의 이름으로 구분하여 해당 자원의 상태를 주고 받는 모든 것
  • WWW(World Wide Web)과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 개발 아키텍처의 한 형식
  • REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일
  • REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나
• RESTful하게 API를 디자인하는 것?
  • API : Application Programming Interface로, 데이터와 기능의 집합을 제공하여 프로그램간 상호작용을 촉진하고 서로 정보를 교환 가능하도록 하는 것
  • API를 설계할 때, 각각의 자원을 나타내는 URI와 메서드만 보고도 어떤 자원에 어떤 행위를 가할 것인지 명확히 파악할 수 있게 디자인 방법(ex. 모든 자원에 명사를 사용함)

 

REST API 구성요소?

• 자원(Resource) : URI
  • 모든 자원에 고유한 ID 존재, 이 자원은 Server에 있음
• 행위(Verb) : HTTP Method
  • HTTP 프로토콜의 Method를 사용
  • GET, POST, PUT, DELETE 제공
• 표현(Representation of Resource)
  • Client가 자원의 상태에 대한 조작을 요청하면, Server는 이에 적절한 응답(Representation)을 보냄
  • Json 혹은 XML을 통해 데이터 주고 받는 것이 일반적

 

REST API의 장단점, 특징?

• 장점
  • HTTP 프로토콜의 인프라를 그대로 활용가능 => 별도의 인프라 구축할 필요 X
  • Rest API 메시지가 의도하는 바를 명확하게 나타내므로, 어떤 자원에 어떤 행위(메소드)를 가할건지 명확히 파악 가능
•  단점
  • 사용할 수 있는 메소드 4개(GET, POST, PUT, DELETE)
  • 구형 브라우저가 아직 제대로 지원해주지 못하는 부분 존재(ex. put, delete 사용 X)
•  특징
  • Server-Client(서버-클라이언트 구조) : 자원이 있는 Server, 자원을 요청하는 Client로 구성
  • Stateless(무상태) : 서버는 각각의 요청을 완전히 별개의 것으로 인식하고 처리 => Client의 context를 서버에 저장하지 않음
  • Cacheable(캐시 처리 가능) : Http 프로토콜을 그대로 사용하므로 기존 인프라에서 지원하는 캐싱 기능 적용 가능
  • Layered System(계층화)
  • Code-On-Demand(optional)
  • Uniform Interface(인터페이스 일관성) : HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능 => 특정 언어나 기술에 종속 X

 

RESTful API를 이용해서 하나의 큰 서비스 애플리케이션을 여러 모듈화된 작은 서비스 애플리케이션으로 나눌 수 있는 서비스란?

• MSA(Micro Service Architecture) : rest api 기능 단위로 서버를 나누어 설계하는 서비스 아키텍쳐
  • 작은 기능의 오류로 인해 전체 서버가 영향을 받는 경우를 줄임
  • 작은 코드 수정으로 전체 서비스를 재배포할 필요를 줄임
  • 서비스 확장성이 높고 지속적인 배포(무중단 서비스)가 필요한 경우 유리한 아키텍쳐
  • 하지만 서버가 여러 개 이기에, 그만큼 모니터링 리소스가 많이 들고 설계가 복잡하여 작은 서비스의 경우 그냥 모놀리식 서비스로 설계하는 게 나음

 

REST API에서 자원(Resource)으로 사용되는 URI와 URL의 차이점?

• URI : Uniform Resource Identifier, 통합 자원 식별자로 인터넷에 있는 자원을 나타내는 유일한 주소, URI의 하위 개념으로 URL과 URN이 있음 => ex. https://board/main?id=30000&page=12
• URL : Uniform Resource Locator, 통합 자원의 위치로 네트워크 상에 자원이 어디 있는지를 알려주기 위한 규약 => ex. https://board/main
• URN : Uniform Resource Name, 통합 자원 이름