REST

박형석·2021년 12월 28일
CS
0

CS

목록 보기
10/10
post-thumbnail

REST

정의

모든 자원(Resource)을 HTTP URI(Uniform Resource Identifier)로 표현하고, '행위'에 해당하는 HTTP Method(GET, PUT, POST, DELETE)를 통해 해당 자원에 대해 CRUD를 지시하는 소프트웨어 아키텍처의 형식

하나의 가이드라인이기 때문에 구현 여부는 개발자에게 달려있다.

  • 웹사이트가 존재하고 각종 이미지와 텍스트 파일 등을 제공할 경우, 각각의 이미지와 텍스트 파일은 고유의 URI를 갖게 됨.
  • Client는 그 URI를 GET(조회), PUT(수정)하는 등의 행동을 통해 통신할 수 있음.

REST의 구성 요소
자원(Resource) : Server에서 제공하는 모든 Resource
행위(Verb) : HTTP Method를 사용하여 Server에서 제공하는 Resource를 취득하는 행위
표현(Representations) : HTTP Method에 응답하여 Server가 전달하는 Resource를 표현하는 방법, HTML, XML, 일반 텍스트, JSON과 같은 다양한 형식이 가능

예시)
HTTP GET /user/hyoh/name
{
"name" : "hyoh" ('name'의 값)
}

REST의 특징

  1. Uniform Interface (유니폼 인터페이스)
    HTTP 표준만 따른다면 어떤 언어 혹은 어떤 플랫폼에서 사용하여도 사용이 가능한 인터페이스 스타일이다. 안드로이드 플랫폼, iOS 플랫폼 등 특정 언어나 플랫폼에 종속되지 않고 사용이 가능하다.

  2. Stateless (상태 정보 유지 안함)
    Rest는 상태 정보를 유지하지 않는다. 서버는 각각의 요청을 완전히 다른 것으로 인식하고 처리를 한다. 이전 요청이 다음 요청 처리에 연관이 되면 안된다.

  3. Cacheable (캐시 가능)
    HTTP의 기존 웹 표준을 그대로 사용하기 때문에 HTTP가 가진 캐싱 기능 적용이 가능하다.

  4. Self-descriptiveness (자체 표현 구조)
    Rest API 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.

  5. Client-Server
    Rest 서버는 API 제공을 하고 클라이언트는 사용자 인증에 관련된 일들을 직접 관리한다. 자원이 있는 쪽을 Server라고 하고 자원을 요청하는 쪽이 Client가 된다. 서로간의 의존성이 줄어들기 때문에 역할이 확실하게 구분되어 개발해야할 내용들이 명확해진다.

  6. Layerd System (계층화)
    클라이언트는 REST API 서버만 호출한다. Rest 서버는 다중 계층으로 구성될수 있으면 로드 밸런싱, 암호화, 사용자 인증 등을 추가하여 구조상의 유연성을 둘 수 있다.

REST API

REST API 설계 규칙

  1. URI는 정보의 자원을 표현해야한다.
    자원의 이름은 동사보다는 명사를 사용한다. URI는 자원을 표현하는데 중점을 두어야 하기 때문에 행위에 대한 표현이 들어가면 안된다.(URI에 HTTP METHOD와 행위에 대한 동사 표현이 들어가면 안된다.)
GET /users/321
  1. 자원에 대한 행위는 HTTP METHOD(GET, POST, PUT DELETE)로 표현한다.
    URI에 자원의 행위에 대한 표현이 들어가지 않는 대신 HTTP METHOD를 통해 대신한다.
GET /users/321 321 ID를 가진 유저 정보를 가져오기
DELETE /users/321 321 ID를 가진 유저 정보를 삭제하기
POST /users 유저를 생성하기

  1. 슬래시 (/)는 계층 관계를 나타내는데 사용한다.

  2. URI 마지막은 슬래시(/)를 사용하면 안된다.

http://restapi.test.com/users/rooms
http://restapi.test.com/users/board

  1. 하이픈 (-)은 URI의 가독성을 높이는데 사용한다.
    불가피하게 긴 URI를 사용하게 될 경우 하이픈을 이용하여 가독성을 높인다.

  2. 언더바(_) 혹은 밑줄은 URI에 사용하지 않는다.
    밑줄은 보기 어렵거나 밑줄 때문에 문자가 가려지기도 한다. 그래서 대신 언더바를 사용하지 않고 하이픈을 이용한다.

  3. URI는 경로에는 소문자가 적합하다.
    URI 경로에는 대문자 사용을 피해야한다. 대소문자에 따라 각자 다른 리소스로 인식하기 때문이다. RFC3986(URI 문법 형식)은 URI 스키마와 호스트를 제외하고는 대소문자를 구별하도록 규정하기 때문이다.

  4. 파일 확장자는 URI에 포함하지 않는다.
    REST API에서는 메시지 바디 내용의 포맷을 나타내기 위한 파일 확장자를 URI 안에 포함시키지 않는다. Accept header를 사용한다.

    Accept header
    Accept header는 요청을 보낼 때 서버에 이런 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할 때 사용. 예를 들어 요청의 헤더로 Accept: text/html 를 보내면 HTML 형식인 응답을 처리하겠다는 뜻

  5. 리소스 간의 관계를 표현하는 방법

GET : /users/{userid}/devices

REST API & RESTful API

  • REST API
    Rest 기반의 규칙들을 지켜서 설계된 API를 Rest API 혹은 Restful API이라고 한다.

  • RESTful API
    REST의 특성에 맞게 설계하는 것을 RESTful이라 칭함. 그리고 그렇게 설계된 시스템에서 사용하게되는 API를 RESTful API라고 함. RESTFUL의 목적은 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것.

    RESTful하지 못한 것

    • CRUD 기능을 전부 GET, POST로만 처리하는 API
    • URI에 자원과 id외 정보가 들어가는 경우
      PUT /users/update-nickname [X]
      PUT /users/:id/nickname [O]

REST vs SOAP

  • SOAP(Simple Object Access Protocol) : HTTP, HTTPS, SMTP등의 프로토콜들을 통해 XML(eXtensibal Markup Language)형태의 메시지 주고 받는 것

  • RESTful (Representational State Transfer) : HTTP프로토콜을 통해 조금더 쉬운 형식으로 데이터 주고받음 (SOAP는 header, body와 같은 복잡한 것을 실어서 보내야함, 또한 데이터 사이즈 커짐)

대부분의 레거시 시스템에서 SOAP를 준수하며, REST는 그보다 뒤에 고려하거나 웹 기반 시나리오에서의 더 빠른 대안으로 여기는 경우가 많음 REST는 유연한 구현을 제공하는 가이드라인 세트고, SOAP는 XML 메시징과 같은 특정 요건이 있는 프로토콜.

REST와 SOAP는 각기 다른 두 가지의 온라인 데이터 전송 방식. 둘 다 웹 애플리케이션 간 데이터 통신을 허용하는 API를 구축하는 방법을 정의. REST(Representational State Transfer)는 시스템을 구축하기 위한 일련의 원칙들(set of architectural principles)이고, SOAP(Simple Object Access Protocol)는 World Wide Web Consortium(W3C)에서 유지관리하는 공식 프로토콜. SOAP는 프로토콜이지만, REST는 프로토콜이 아니라는 점이 주요 차이점.

참고
https://ko.wikipedia.org/wiki/REST
https://ios-development.tistory.com/26?category=889410
https://velog.io/@stampid/REST-API%EC%99%80-RESTful-API
https://ios-development.tistory.com/58?category=894545

profile
박형석
IOS Developer
이전 포스트

Packet & FLAG & TCP

0개의 댓글