About Packet & RESTful
Packet
- Packet은 데이터 덩어리, 데이터 뭉치이다.
- 데이터를 담아서 보내는 상자라고 생각할 수 있다.
Header
- Packet에서 데이터의 메타데이터를 담는 부분이다.
Body
- Packet에서 데이터의 유저데이터를 담는 부분이다.
HTTP 프로토콜 방식, XML & JSON
HTTP 프로토콜
- HTTP(Hypertext Transfer Protocol)는 인터넷상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.
- Application 계층의 프로토콜로 TCP/IP 위에서 동작한다.
- 모든 종류의 데이터를 전송할 수 있다.
- 하이퍼텍스트 기반으로(Hypertext) 데이터를 전송(Transfer)하겠다는 것은 링크기반으로 데이터에 접속하겠다는 의미이다.
- 데이터 전송의 방식에는
GET,POST,PUT,PATCH,DELETE등이 있다.
->GET: 데이터를 조회할 때 사용
->POST: 데이터를 생성할 때 사용
->PATCH: 데이터를 수정할 때 사용
->DELETE: 데이터를 삭제할 때 사용
XML & JSON
예전에는 데이터의 양이 많지 않았기 때문에 FORM 형태로 주로 데이터를 주고 받았다. 그러나 시대가 변하면서 주고 받는 데이터가 많아지고 명세를 맞추기가 너무 어려워졌다. 그래서 등장한 것이 데이터 포맷(Data format - ex. XML, JSON)이다. 현재는 JSON이 XML보다 더 가볍고 간편하다(태그가 필요없다). XML에서 데이터를 뽑아내려면 XML Parser가 필요하고 JSON에서 데이터를 뽑아내려면 JSON Parser가 필요한 것은 같지만 객체 단위 매핑이 더 쉽기 때문이다.
쿼리스트링(query string)
?를 붙이고 뒤에 찾고 싶은 데이터를 던지는 것으로 주로 필터링을 할 때 사용한다.
API & Interface
Interface
좁게는 컴퓨터 및 소프트웨어 조작 방식을 말하며 넓게는 서로 다른 두 물체 사이에서 상호 간 대화하는 방법을 의미한다.
API
API란 서버와 클라이언트 사이에 상호작용을 할 수 있게 만들어주는 버튼과 같은 존재이다. 즉, 클라이언트와 서버라는 두 영역이 API라는 버튼으로 맞닿아 있고 그 버튼을 통해 서버와 클라이언트가 상호작용을 한다.
하지만 같은 기능을 가진 버튼이 다른 디자인을 가지는 것처럼 API도 기능은 같지만 프로토콜 방식이 다를 수 있다. 그래서 통일성을 주기 위해 RESTful API가 등장했다.
RESTful API는 지속 가능한, 계속 사용할 수 있는 통일성 있는 API라는 뜻을 가지고 있고, 이는 일종의 규칙으로 볼 수 있다.
REST API
REST API
REST란 Representational State Transfer 의 약자로 2000년도에 로이 필딩 (Roy Fielding)의 박사학위 논문에서 최초로 소개되었다고 한다.
소프트웨어 프로그램 개발의 아키텍처의 한 형식이며, 직역하면 대표적인 상태 전달이다.
Domain/URI로 이뤄진 URL 형식으로 작성된다.
REST의 목적
- 구성요소 상호작용의 규모 확장성
- 인터페이스의 범용성
- 구성요소의 독립적인 배포
- 중간적 구성요소를 이용한 응답 지연 감소, 보안 강화, 레거시 시스템 캡슐화
REST의 제약조건
- Client - Server (클라이언트 - 서버 형태)
-> 클라이언트 서버 형태의 원칙은 관심사의 명확한 분리를 말하며, 이를 지킴으로써 서버와 클라이언트의 역할을 분명히 함과 동시에 서버의 구성요소가 단순화되고 확장성이 향상되어, 여러 플랫폼을 지원할 수 있게 된다. - Stateless (무상태성)
-> 무상태성 원칙은 서버에 클라이언트의 상태 정보를 일절 저장하지 않음을 이야기 한다. 서버는 단순히 들어오는 요청만을 처리하여 구현을 단순화 하되, 클라이언트의 모든 요청은 서버가 요청을 알아듣는 데 필요한 모든 정보를 알고 있어야 한다. 이를 테면, 어떤 메소드를 요청했는지, 여기에 필요한 정보는 무엇인지 등을 이야기 한다. - Cache (캐시 기능)
-> 캐시 기능은 클라이언트의 요청을 캐싱한다는 이야기이다. HTTP의 기능 중 캐시 기능을 적용한 것이다. - Uniform Interface (인터페이스 일관성)
-> 인터페이스 일관성 원칙은 URI를 가능한 지정된 리소스에 균일하고, 통일된 인터페이스를 제공해야 하는 원칙으로 아케텍처를 단순하게 분리하여 확장이 쉽도록 구현해야 한다는 원칙이다. 대표적으로는 각 Entity 별로 자원을 식별하는 방법, 혹은 HATEOAS를 이용하는 방법을 이야기 한다. HATEOAS란, 클라이언트에 응답하는 형식을 단순히 결과 데이터만 제공해주는 것이 아닌 URI를 함께 제공해야 한다는 원칙을 말한다. - Layered System (계층화 시스템)
-> 계층화 시스템 원칙은 애플리케이션 서버가 중계 서버(Proxy, Gateway)나 로드 밸런싱, 공유 캐시 등을 이용하여 확장성 있는 시스템을 구현해야 한다는 원칙이다. - Code-On-Demand (코드 온 디맨드)
-> 코드 온 디맨드의 원칙은 반드시 지켜야 할 필수 원칙은 아니다. 이 원칙은 클라이언트가 서버에서 JavaApplet, Javascript 실행 코드를 전달 받아 기능을 일시적으로 확장할 수 있어야 한다는 원칙이다.
REST API 설계
REST API의 구성
REST API는 HTTP의 메소드, URI로 이루어진 API 서버이므로, 필요한 것은 요청과 응답 이렇게 2가지가 존재하고, 어떠한 요청에 필요한 데이터와 그 결과 모델을 구성해야 한다.
- 자원(Resource) - URI
- 행위(Verb 또는 Action) - HTTP Method
- 표현(Representations) - HTTP Message Body
REST API의 중심 규칙
- URI는 정보의 자원을 표현해야 한다.
- 자원의 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현해야 한다.
HTTP Method
GET: 데이터를 조회할 때 사용POST: 데이터를 생성할 때 사용PATCH: 데이터를 수정할 때 사용DELETE: 데이터를 삭제할 때 사용
이를 통해 CRUD(Create, Read, Update, Delete) 를 구현한다.
URI 설계 시 주의할 점
- 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용한다.
- URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
- 하이픈(-)은 URI 가독성을 높이는데 사용한다.
- 밑줄(_)은 URI에 사용하지 않는다.
- URI 경로에는 소문자가 적합하다.
- 파일 확장자는 URI에 포함시키지 않는다.
리소스 간의 관계를 표현하는 방법
- 다음과 같은 방법으로 관계를 표현한다.
/리소스명/리소스 ID/관계가 있는 다른 리소스명 - 관계명이 복잡하다면 이를 서브 리소스에 명시적으로 표현하는 방법이 있다.
