Restful한 API 에 대해

RESTFUL API

• REST/RESTful REST의 정의
  “Representational State Transfer” 의 약자
  자원을 이름으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다.
  즉, 자원(resource)의 표현(representation) 에 의한 상태 전달 REST의 구체적인 개념
  HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.
  즉, REST는 자원 기반의 구조(ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고 HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
  웹 사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다. 단점
  표준이 존재하지 않는다.
  사용할 수 있는 메소드가 4가지 밖에 없다.
  HTTP Method 형태가 제한적이다.
  브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
  구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.
  PUT, DELETE를 사용하지 못하는 점
  pushState를 지원하지 않는 점 REST가 필요한 이유
  ‘애플리케이션 분리 및 통합’
  ‘다양한 클라이언트의 등장’
  최근의 서버 프로그램은 다양한 브라우저와 안드로이폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
  이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었다. REST 구성 요소
  자원(Resource): URI
  모든 자원에 고유한 ID가 존재하고, 이 자원은 Server에 존재한다.
  자원을 구별하는 ID는 ‘/groups/:group_id’와 같은 HTTP URI 다.
  Client는 URI를 이용해서 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청한다.
  행위(Verb): HTTP Method
  HTTP 프로토콜의 Method를 사용한다.
  HTTP 프로토콜은 GET, POST, PUT, DELETE 와 같은 메서드를 제공한다.
  표현(Representation of Resource)
  Client가 자원의 상태(정보)에 대한 조작을 요청하면 Server는 이에 적절한 응답(Representation)을 보낸다.
  REST에서 하나의 자원은 JSON, XML, TEXT, RSS 등 여러 형태의 Representation으로 나타내어 질 수 있다.
  JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.
  
• HTTP Method

  • GET

  • POST

  • PATCH

  • PUT

  • DELETE

    ** PATCH와 PUT의 차이점 : PUT은 자원 통째로 교체 , PATCH는 자원의 일부 교체

• HTTP Response Code 의미 = HTTP 상태코드
  
• Reverse Proxy 클라이언트로부터의 요청을 받아서(필요하다면 주위에서 처리한 후) 적절한 웹 서버로 요청을 전송한다. 웹 서버는 요청을 받아서 평소처럼 처리를 하지만, 응답은 클라이언트로 보내지 않고 Reverse Proxy로 반환한다. 요청을 받은 Reverse Proxy는 그 응답을 클라이언트로 반환한다. 통상의 프락시 서버는 LAN -> WAN의 요청을 대리로 수행하지만 Reverse Proxy는 WAN -> LAN의 요청을 대리한다. 클라이언트로부터의 요청이 웹서버로 전달되는 도중의 처리에 끼어들어서 다양한 전후처리를 시행할 수가 있게 된다. **리버스 프록시 형태를 지향해야한다

  Reverse Proxy를 사용하여 URL 기준으로 요청을 분기할 경우 메모리 사용효율을 향상할 수 있다.
  옛날에는 Tomcat의 정적 리소스 처리 성능이 낮았기에 Apache를 프록시로 붙여서 사용하는 케이스가 많았다.
  ( 하지만 현재는 Tomcat의 정적 리소스 처리 성능이 나쁘지 않다.
  또한 맨 앞단에 정적 리소스 처리를 위한 캐시 서버를 두는 경우엔 더더욱 영향이 적을 것으로 예상된다. )
  게다가 정적 리소스 처리(보통은 이미지나 js, css 등임)만을 위해 Proxy를 두는 것은 구조상의 복잡함을 야기하게 된다.