Skip to content

Latest commit

 

History

History
60 lines (36 loc) · 2.17 KB

ApiDesignPattern.md

File metadata and controls

60 lines (36 loc) · 2.17 KB

API 디자인 패턴

SOAP

💡 컴퓨터 네트워크 상에서 데이터 교환 포맷을 표준화하기 위해 개발된 프로토콜

기본 데이터 포맷으로 XML 사용

XML: HTML과 비슷한 문자 기반의 마크업 언어로 데이터를 저장하고 전달하려는 목적으로 만들어짐

  • 자체적으로 보안처리를 위한 SSL 지원, 자체 표준 보안 기능 가지고 있음
  • 작은 데이터를 전송하려해도 XML 구조에 따라 많은 코드를 작성해야 함
  • 메시지 전송 표준이 정해져 있어 메시지 작성이 복잡함

REST

💡 HTTP 요청 메시지로 서버의 데이터를 조작하기 위한 디자인 패턴
  • 웹 애플리케이션과 서버 간의 통신을 위한 제약 조건과 규칙 제시해 확장성 갖추고 동작
  • HTTP를 그대로 활용해 웹 애플리케이션에서의 동작 유리 & HTTP만의 장점 최대한 활용
  • 자원, 행위, 표현 → 설계

자원: 클라이언트의 요청과 서버의 응답으로 주고받는 데이터 자원을 URI로 명시

URI: 도메인 주소를 통해 고유한 자원을 식별하는 용도 (URL을 포함하는 상위 개념)

EX) URL: https://www.google.com/user, URI: https://www.google.com/user/3

GET /user/show/3 --- (x) GET /getUsers/3 ---- (x)

GET /users/3 ------------(o) GET /users/profile/3 ----(o)

행위: HTTP 프로토콜에서 지원하는 메서드를 사용해 지정한 자원에 대한 조작 요청 (CRUD)

CRUD: Create, Read, Update, Delete → 이에 사용하는 메서드: POST, GET, PUT/PATCH, DELETE

표현: 특정 자원에 대한 요청의 결과로 반환되는 특정 시점의 자원 상태를 의미

단점 👎🏻

  • 언더페칭 - API 요청 결과와 필요한 데이터를 한 번의 요청으로 목적을 달성하지 못하는 것
  • 오버페칭 - API 요청 결과와 필요 이상의 데이터를 조회하는 것

GraphQL

💡 개발자가 API를 좀 더 쉽게 구축하고 사용할 수 있도록 설계된 쿼리 언어 및 서버 측 런타임

클라이언트가 요청한 데이터를 서버에서 빠르게 조회에 응답하기 위해 만들어짐