REST API 에 대해 알아보자

Jeong·2023년 9월 27일
0

REST API

목록 보기
1/1
post-thumbnail

키워드

최종 목표

학습 목표

REST API 에 대해 알아보자.

F/E 와 B/E 은?

커다란 시스템을 만들 때, 시스템을 하나로 만들 수도 있지만, 보통은 시스템을 여러 Tier(또는 Layer) 로 구분한다.

프로그램을 하나로만 만드는게 아니라, 여러 개의 구성된 묶음으로 만든다. 여러 조각.

UI 를 다루는 Layer, 비지니스 로직을 다루는 Layer 이런 식으로.

일반적으로

Tire 는 물리적인 구분
Layer 는 논리적인 구분

버튼 보여주고, 글 보여주고

계산을 해요, 값을 만들어요

프로그램은 원격으로 쓰게 된다.

다른 곳을 가서 써도 동일하게 보임. 내 컴퓨터 안에서만 돌아가는 게 아님.
구글 독스

이렇게 프로그램을 여러 조각으로 나눴을 때, 사용자에게 가까운 부분이 F/E 라고 한다. 먼 부분이 B/E 라고 한다.

F/E 와 B/E 는 어떤 식으로든 연결이 되야 한다.

얘네를 물론 한 프로그램 안에서 할 수도 있다.

하지만 이전에 말했듯이 얘네도 Tier 로 나눠지게 된다.

얘네를 물리적으로 분리를 해놓고
사이의 통신은 HTTP 로 해준다. (이건 통신 규약일 뿐이다. HTTP 자체는 프로토콜일 뿐이고)
다양한 웹 기술을 이용한다. 그리고 동시에 REST API 를 사용한다.

REST 라는 아키텍쳐 스타일을 따르는 API 이다.

REST API 만 가능한 건 아니다. GraphQL, SOAP 등 다른 것도 사용할 수 있다.

물리적으로 완전히 나눠보면

서버는 백엔드다. 클라이언트는 프론트엔드다.

프론트엔드를 개발한다?
웹 브라우저(클라이언트 프로그램) 위에서 돌아가는 자바스크립트 프로그램을 만드는 것.

백엔드를 개발한다?
옛날에는 HTTP 로 통신하는 걸 다 짜줬지만 지금은 Tomcat 웹 애플리케이션 서버가 떠있고 그 위에서 돌아가는 자바 서블릿, 스프링 부트 를 통해서 프로그램을 개발하는 것

이게 아니라면 Tier 로써의 백엔드라고 하면
소켓 프로그래밍부터 다 만드셨나요?
브라우저부터 다 만드셨나요?
이렇게 된다.

우리가 모든 부분을 만드는 게 아니라, 서비스를 제공하기 위한 부분들을 만드는 것이다.

API 란?

Application Programming interface

= 애플리케이션을 만들기 위한 인터페이스이다.

=> 객체 지향에서의 인터페이스와는 조금 다르긴 하지만,
시그니처, 명세, 스펙

구현과 상관없다!

이렇게 쓰는 거야. 이렇게 될 거야. (약속, 계약) => 명세, 스펙 => 을 모아놓을 것이 인터페이스이다.

interface 로 얻을 수 있는 효과

  • Communication
    • 구현과 상관없이, 어떻게 소통할지에 대해서 명세
  • Specification
    • 어떻게 할지 드러내지 않는다. interface 만 있기 때문. 연결점만 있는 것.
  • Imformation Hidong (Principle)=원칙
  • 즉, 무슨 일이 일어나는지는 어딘가의 뒤로 감춰진다. (=정보은닉) 내부가 아니라, 벽치고 뒤에 있는 느낌
  • 어떻게 기술적으로 정보은닉을 할까 -> 캡슐화 != 정보은닉
  • 한 곳에 묶어서 내부를 만든다. 내부와 외부를 연결은 인터페이스로만 가능하다. -> 밖으로 안에가 드러나지않는다.
  • 기술적으로 정보 은닉을 하는 방법 중에 하나가 캡슐화이다.
  • Implementaion
  • 스위치라고 했을 때 우리는 내부 작동을 전혀 모르지만 On/oFF 는 함. 구현과 구분하기 위해서 인터페이스를 많이 쓴다.

=> 결론

프로그래밍 하기 위해서 나혼자 할 수 없음. 누군가가 제공함.

스위치가 있어서 눌렀더니 뭔가가 일어나는 스펙에 대한 것.

인터페이스를 쓰는 방법은?

그냥 누르는 스위치

슬라이드 스위치

다이얼 스위치

쓰는 방법이 다를 수 이싿.

쓰는 방법이 원칙을 따르면 좋겠다고 생각. => 그 중 하나로 REST 원칙를 따르자.

REST 란?

Representaion State Transfer (표현적인상태전송)

REST

로이 필딩이 논문을 그중에 REST 에 대한 게 있다. 아키텍쳐 스타일. 네트워크를 베이스(기반으로)로 하는 소프트웨어.

REST는 아키텍쳐를 위한 아키텍쳐 스타일로 볼 수 있다.

REST 제약 조건

  • String With Null Style
  • C
  • S
  • C
    여기까지는 웹에 있는 거
  • Uniform Interface -> 핵심

필딩 제약 조건 (4가지)

  • URI 등으로 리소스를 식별할 수 있다.

  • 표현으로 리소스를 조작한다.

  • 자기서술적 메시지여야한다.

    • 여러 layer 가 나눠져이썽ㅆ다. 그 안에서 얘를 처리하거나 변환할 수 있어야 되는데, 내가 누군지 알아야 한다. name <- 컴퓨터: 이게 뭔데? 사람: 이름이네
    • 그래서 MINE 타입으로 설명을 넣어야 한다.

  • 줄여서 HATEOAS 라고 부른다.
    -> rest api 얘기할 때 까다로운 부분 (= 많이 안지킴)

REST 를 얘기할 때 '필딩 제약 조건' 을 따르느냐 안 따르느냐에 집중한다.

REST API

API 를 구성할 때 REST 하게 만들거야.
근데 원래 REST 는 API 를 위한 아키텍쳐는 아니다.
웹에서 일반적인 경우에 특화된 것 뿐.

하지만 제약 조건을 완전히 지키지 않더라도 조금만 지키더라도 aPI 를 만들 때 굉장히 유용하게 활용할 수 있다. (일종의 표준을 따르는 거니까)

리소스는 무엇? 추상O 실제X

파일 자체가 리소스(X) 서버에 저장된 무언가가 아님!

리소스는 모든 시간에 통용되는 엔티티의 집합이다.

엘리스가 키가 커지더 작던 엘리스이다. (내부 속성이 바뀌어도 엘리스이다)

리소스와 표현을 분리함

Representaion -> Data + MetaData === > 사실상 HTTP Message

리소스, 표현, 실제 데이터 => 얘네를 구분하는게 레스트에서 강력한 부분

2번 잘 정리해보장

스펙 정한 거를 API 문서라고 한다. =메뉴열

메뉴열을 보고

단계가 있음. 리소스만 도입해도 : 레스트에 한발 다다갔군요!
2단계 리소스에(URL) 대한 처리를 HTTP MEthod 를 썼어

로이 필딩이 대노해도
엽계에선 레벨2까지만 만족해도 레스트 API라고 부른다

논문은 REST 를 다룰 것이다.

REST API 가 뭔가요? 설명하기 복잡합니다... 앞으로 공부하면서 일반적으로 REst api 는 이런 개념으로 통용적으로 쓰는 구나 를 파악하자.

아하! 포인트

빡세게 이해할 필요는 없다.

REST API 에 대한 개념없이 REST API 를 작성하고 있었다.
통용되는 규칙을 알게 모르게 지키고 있었다는 사실이 충격적이다.
REST API, Resource 의 개념이 확실히 와닿진 않지만 남은 강의를 일단 들어봐야겠다.

다음에는?

REST API 를 이해하기 위한 구성요소들을 하나씩 알아보자.

profile
Jeong
성장중입니다 🔥 / 나무위키처럼 끊임없이 글이 수정됩니다!

0개의 댓글