minyule.log
로그인
minyule.log
로그인
RESTful API 란
김민영
·
2023년 1월 14일
팔로우
0
개발상식
0
CS 스터디
목록 보기
10/32
REST
Representational State Transfer
자원의 표현: 자원의 표현에 의한 상태 전달
상태(정보) 전달: ex) JSON, XML
개념
HTTP URL을 통해 자원 resource를 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용
CRUD Operation
Create: POST (생성)
Read: GET (조회)
Update: PUT (수정)
Delete: DELETE (삭제)
HEAD: HEAD (header 정보 조회)
장단점
장점
HTTP 프로토콜 인프라를 그대로 사용하므로 REST API를 위한 별도 인프라 구축 필요 없음.
HTTP 프로토콜와 함께 추가 장점이 있으며, 표준 프로토콜 따르는 모든 플랫폼에서 사용 가능.
Hypermedia API 기본 지키며 범용성 보장
REST API 메시지가 의도하는 바를 명확히 나타냄.
여러 서비스 디자인에서 발생할 수 있는 문제 최소화
서버, 클라이어트 역활 명확히 분리
단점
표준이 없음.
사용할 수 있는 메소드가 4가지로 제한됨
구형 브라우저가 지원하지 못하는 부분 존재. (PUT, DELETE, pushState)
필요성
애플리케이션 분리, 통합
다양한 클라이언트 등장
최근 서버 프로그램은 다양한 브라우저와 안드로이드, 아이폰 등 모바일 기기에서도 통신 가능해야 함.
멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법으로 REST
구성요소
자원(Resource) URI
모든 자원에 고유 ID 존재, 자원은 Server에 존재
자원을 구별하는 ID는 '/groups/:group_id'와 같은 HTTP URI임.
Client는 URI를 이용하여 자원 지정, 해당 자원 상태(정보)에 대한 조작을 Server에 요청
행위(Verd) HTTP Method
HTTP 프로토콜의 Method 사용 (POST, GET, PUTk DELETE)
표현(Representation of Resource)
Client가 자원의 상태(정보)에 대한 조작 요청 시, Server는 적절한 응답(Representation) 보냄
REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타낼 수 있음.
특징
Server-Client 구조
자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
REST Server: API 제공, 비즈니스 로직 처리 및 저장
Client: 사용자 인증, context(세션, 로그인 정보) 등을 직접 관리, 책임
상호 의존성 감소
Statelsee 무상태
HTTP 프로토콜은 Stateless Protocol. REST도 무상태성
Client의 context를 Server에 저장하지 않음
세션, 쿠키 등.
Server는 각각의 요청을 별개의 것으로 인식, 처리
각 API 서버는 Client의 요청만을 단순 처리
이전 요청이 다음 요청 처리에 연관되면 안됨.
이전 요청에 의한 DB 수정, DB 결과에 의한 연관은 허용.
Server 처리 방식에 일관성. 부담 감소, 서비스 자유도 증가
Cacheable 캐시 처리 가능
웹 인프라 사용
캐싱 기능 사용 가능.
HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그, E-Tag를 이용하여 캐싱 구현 가능
대용량 요청을 효율적으로 처리하기위해 캐시 요구
캐시 사용하여 응답 속도 향상, REST Server 트랜잭션 발생하지 않음. 전체 응답시간, 성능, 서버의 자원 이용률 향상
Layered System 계층화
Client는 REST API Server만 호출
REST Server는 다중 계층으로 구성됨
API Server는 순수 비즈니스 로직 수행하고, 그 앞 단에 보안, 로드밸런싱, 암호화, 사용자 인증 등 추가하여 구조상 유연성
로드밸런싱, 공유 캐시 등으로 확장성, 보안성 향상
PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체 사용 가능
Code-On-Demantd(optional)
Server로부터 스크립트 받아 Client에서 실행
Uniform Interface 인터페이스 일관성
URI로 지정한 Resource에 대한 조작을 통일되고 한정적인 인터페이스로 수행
HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용 가능
특정 언어, 기술 종속 x
REST API
정의
API: Application Programming Interface
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용 촉진, 정보 교환 가능하게 함.
REST API
REST 기반의 API 정의
특징
REST 기반으로 시스템 분산. 확장성, 재사용성 향상. 유지보수 및 운용 편리
REST는 HTTP 표준 기반이므로 , HTTP를 지원하는 프로그램 언어로 클라이언트, 서버 구현 가능
델파이 클라이언트 뿐 아니라, 자바, C#, 웹 등으로 클라이언트 제작 가능
기본 규칙
도큐먼트 : 객체 인스턴스, 데이터베이스 레코드와 유사한 개념
컬렉션 : 서버에서 관리하는 디렉터리라는 리소스
스토어 : 클라이언트에서 관리하는 리소스 저장소
URI는 정보의 자원 표현
resource는 동사보다는 명사를, 대문자보다는 소문자를 사용.
resource의 도큐먼트 이름은 단수명사
resource의 컬렉션 이름은 복수명사
resource의 스토어 이름은 복수명사
자원에 대한 행위는 HTTP Method로 표현
POST, GET, PUT, DELETE 등
URI에 HTTP Method가 들어가면 안 됨. 동사가 들어가면 안 됨.
경로 부분 중 변하는 부분은 유일 값으로 대체. id 사용
설계 규칙
슬래시 구분자 / 는 계층 관계 나타냄
URI 마지막에는 / 포함하지 않음
~은 URI 가독성을 높이기 위해 사용
_은 사용하지 않음
URI 경로는 소문자 적합
URI 문법 형식은 URI 스키마와 호스트를 제외하고 대소문자 구별하도록 규정함
파일 확장자는 URI에 포함하지 않음.
Accept header 사용
리소스 간 연관관계 있는 경우
/리소스명/리소스 ID/관계있는 다른 리소스명 형식으로 사용
응답 상태 코드
1xx: 전송 프로토콜 수준의 정보 교환
2xx: 요청 성공 수행
3xx: 클라이언트는 요청 완료 위해 추가 행동 필요
4xx: 클라이언트 잘못된 요청
5xx: 서버쪽 오류
RESTful
정의
REST라는 아키텍처 구현하는 웹 서비스를 나타내기 위해 사용하는 용어
REST API를 제공하는 웹 서비스를 RESTful 하다고 함.
REST를 REST 답게 사용하기 위함. REST 원리를 따르는 시스템을 의미
목적
이해하고 사용하기 쉬운 REST API 만들기
RESTful한 API 구현하는 목적은 성능 향상이 아니라, 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것.
성능이 중요한 상황에서는 필수가 아님.
RESTful 하지 못한 예시
CRUD를 모두 POST로 처리
route에 resource, id외 정보가 들어가는 경우
레퍼런스
https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html
김민영
노션에 1차 정리합니당 - https://cream-efraasia-f3c.notion.site/4fb02c0dc82e48358e67c61b7ce8ab36?v=
팔로우
이전 포스트
TDD 란 무엇이며 어떠한 장점이 있는가
다음 포스트
운영체제란?
0개의 댓글
댓글 작성