SpringBoot #3.3 Rest(ful) API

텐저린티·2023년 7월 5일
0

데브코스

목록 보기
25/41
💡 REST API = REST 아키텍처 스타일 준수하는 API

REST

  • Representational State Transfer
  • WWW 같은 분산 하이퍼미디어 시스템 위한 소프트웨어 아키텍처 방식
  • 네트워크 아키텍처 원리 모음
    • 자원 정의, 자원 주소 지정 방법 = 네트워크 아키텍처 원리
  • HTTP 상에서 SOAP, 쿠키, 세션 트래킹 같은 별도 전송계층 없이 웹 자료를 전송하기 위한 간단한 인터페이스

API

  • Application Programming Interface
  • 서브루틴 선언, 프로토콜, 소프트웨어 구성 도구 집합
  • 다양한 소프트웨어 컴포넌트 간 의사소통을 명백하게 해주는 방법
  • 웹 기반 시스템, 운영체제, 데이터베이스 시스템, 컴퓨터 하드웨어, 소프트웨어 라이브러리 등 다양한 곳에서 쓰임

REST 아키텍처 스타일

  • 클라이언트 - 서버
    • UI 관심과 데이터 저장 관심을 분리
    • 클라이언트 이식성, 서버 규모확장성 개선
  • stateless
    • 클라-서버 간 통신 상태 없음
    • 모든 요청에 필요한 모든 정보 포함 → 가시성 향상
    • 요청 실패 시 복원 쉬움 → 신뢰성
    • 규모확장 용이
  • 캐시
    • HTTP 의 캐싱 기능 적용 가능
    • HTTP 프로토콜의 Last-Modified 태그, E 태그 이용해 캐싱 구현 가능
  • 균일한 인터페이스
    • URI
    • 지정 리소스에 대한 조작 통일
    • 지정 리소스에에 대한 한정적인 인터페이스
  • 계층화된 시스템
    • REST 서버는 다중 계층으로 구성
    • 보안, 로드 밸런싱, 암호화 계층 추가 → 구조 유연성
    • 프록시, 게이트웨이 같은 네트워크 기반 중간매체 사용 가능

뤼촤rr드손 성숙도 모델

  • 레벨 높을수록 REST 스타일 아키텍처임
  • Lv3. Hypermedia Controls
    • HATEOAS
    • 모든 리소스에 대한 연결성이 있어야 함
    • 리소스에 대한 가능한 행위를 제공해야 함
  • Lv2. HTTP Verbs
    • 메소드를 사용
    • 기존 post만 사용하던 방식에서 기능별로 적절한 메소드를 호출할 수 있게 된 것
    • get, post, update, delete
  • Lv1. Resouces
    • 리소스 단위로 여러 개의 엔드포인트가 생김
    • 하지만 하나의 리소스에 대해서 다양한 Representations 가 가능해야 함
  • Lv0. The Swamp of POX
    • 이건 REST가 아닌것 → 리소스가 없기 때문
    • SOAP 기반 프로토콜
    • 외부에 있는 메소드 호출
    • url이 하나만 있음
      • xml로 요청

Representations

  • 리소스의 특정 시점 상태 반영한 정보
  • 리소스에 대한 여러 표현 중 하나
  • representation = representation data + representation metadata
  • ex) GET /hello
    • representation data : hello
    • representation metadata
      • Content-Type: text/plain
      • Content-Language : en
      • resource = hello
    • represnetation metadata
      • Content-Type: text/plain
      • Content-Language : ko
      • resource = 안녕하세요
    • representation metadata
      • Content-Type : application/json
      • Content-Language : en
      • resource = {”message”:”hello”}

HATEOAS

  • Lv3. 하이퍼미디어 제어 수준의 REST 성숙도 방법
  • Hypermedia as the Engine of Application State
  • links 속성에 있는 것처럼 각 리소스에 대해서 할 수 있는 행동에 대해서 명시해줌
{
"id": "1",
"contents": " .",
다시합부공
"createAt": "2020-01-01 12:00:00",
   "likes": 2,
   "likesOfMe": false,
   "comments": [],
   "writer": { "id": "2", "email": "harry@gmail.com", "name": "harry" },
   "links": [
      {"rel": "self", "action": "GET", "href": "/api/v1/posts/1"},
      {"rel": "deletePost", "action": "DELETE", "href": "/api/v1/posts/1" },
      {"rel": "getWriter", "action": "GET", "href": "/api/v1/users/1" },
      {"rel": "addComment", "action": "POST", "href": "/api/v1/posts/1/comments"}
] }

API 설계

  1. URI = 정보 자원 표현
    1. 리소스는 명사 지향
    2. 행위는 동사 지향 (HTTP Method ; GET, POST, PUT, DELETE)
  2. 슬래시 구분자(/) 는 계층 관계 표현
  3. URI 마지막 문자로 슬래시(/) 포함 X
  4. 하이픈(-)은 URI 가독성 향상 위해 사용

RestController

  • @RequestBody
  • @ResponseBody
  • @RestController
    - 일반적인 Controller 에 @ResponseBody 포함된거
    - 모든 메소드에 @ResponseBody 적용됨.
profile
개발하고 말테야

0개의 댓글

관련 채용 정보