Restful Web Service

REST( REpresentational State Transfer )?

• REST는 웹 표준 기반 아키텍처이며 데이터 통신에 HTTP 프로토콜을 사용
• resource를 정의해서 CRUD 인터페이스를 제공.( 그 리소스가 있는 곳에 데이터를 요청 )

• REST 아키텍처에서 REST 서버는 단순히 resource에 대한 액세스를 제공하고 REST 클라이언트는 자원에 액세스하고 나타낸다.
• 각 resource는 URI / 글로벌 ID로 식별된다.
• REST는 Text, JSON 및 XML과 같이 다양한 형태로 리소스를 나타낸다. ( JSON 가장 많이 사용 )
• Client 부분은 Server에서 Json을 파싱해서 뿌려주기 때문에 파싱할 수 있는 것(Json pasor)이 필요하다.

 

출처: https://www.seobility.net/en/wiki/REST_API

 

예시

HTTP Method	URI	Operation
GET	/api/users	returns a list of users
GET	/api/users1	returns the user with id 1
POST	/api/users	creates a new user
PUT	/api/users/3	updates the user with id 3
DELETE	/api/users/4	deletes the user with id 4
DELETE	/api/users	deletes all the users

C - Post

R - Get

U - Put
D - Delete

 

RESTful Web Service

- 구조

 

 

• 중간에서 Rest API만 만들어 놓으면 클라이언트가 어떤 플렛폼을 사용하든지 HTTP를 사용하여
  서비스를 제공할 수 있다.  (서버와 클라이언트가 완전히 분리됨)
• 클라이언트가 URI를 보내면 서버는 응답코드를 보내는 방식으로 진행
• Pattern:
  • things(resource)를 수행되는
  • Command(Method)들은
  • response(message)를 발생시킨다.
• 예시: client -> CREATE /things X, Y, Z, Server -> 201 CREATED (things was created)

- Representation of Resources

• Resources
  • XML에서는 태그를 사용하여 정의
    <user>
     <id>1</id>
     <name>kwon</name>
    </user>
  • Json는 key : value로 정의
    {
     "id": 1,
     "name: "kwon"
    }
    

 

Browser sends arequest message 구조

 

• Request Message
  • Verb:
    - GET, POST, DELETE, PUT 등과 같은 HTTP 메소드를 나타낸다.
  • URI: 서버의 리소스를 식별
  • HTTP VERSION:
    - ex) http 1.0
    http 1.0과 1.1의 차이는?
    - 1.1은 한번 연결하면 계속 통신 가능 1.0은 한번 통신하면 끊어버린다.
    http 1.1과 2.0의 차이는?
    - 가장 큰 차이는 속도
    - 2.0같은 경우는 헤더를 압축해서 보내기도하고, 한번의 연결로 동시에 여러 메시지를 주고 받을 수도 있다.
  • Request Header:
    - HTTP 요청 메시지의 메타 데이터를 키-값 쌍으로 포함
    ex) 클라이언트 유형, 클라이언트가 지원하는 형식, 메시지 body 형식, 캐시 설정 등
    - Content Negotiation
    => 클라이언트와 서버 사이의 협상 ==> 클라이언트가 처리할 수 있는 것을 확인하고 서버에서 그 방식으로 응답을 해준다.. 
  • Request Body:
    - 메시지 내용 또는 리소스 표현.

 

Server returns a response message 구조

 

• Response Message
  • Response Code:
    - 요청 된 리소스의 서버 상태를 나타낸다.
    - 예를 들어, 404는 리소스를 찾을 수 없음을 의미하고 200은 응답이 정상임을 의미.
    2xx Success (200 OK, 201 Created…)
    3xx Redirection (303 See other)
    4xx Client error (404 Not Found)
    5xx Server error (500 Internal Server Error)
  • HTTP VERSION:
    Client와 같음
  • Response Header:
    - HTTP 응답 메시지의 메타 데이터를 키 값 쌍으로 포함
    ex) 컨텐츠 길이, 컨텐츠 유형, 응답 날짜, 서버 유형 등
  • Response Body:
    - 응답 메시지 내용 또는 리소스 표현
• Addressing
  - REST 아키텍처의 각 자원은 URI (Uniform Resource Identifier)로 식별된다.
  형식:
  <protocol>://<service-name>/<ResourceType>/<ResourceID>
  => http://localhost:8080/springMVC/users/1
  • 표준 URL 생성
    • user라고 할 수도 있지만 관례상 users라고 줘라
    • 스페이스를 주지말고 언더바나 하이픈을 주어 문자를 연결하라
    • 소문자를 사용해서 URI를 만들어라 
    • 이전 버전과의 호환성 유지해라.
      웹 서비스는 공용 서비스이므로 일단 공개 된 URI는 항상 사용 가능해야한다.
      URI가 업데이트되는 경우 HTTP 상태 코드 300을 사용하여 이전 URI를 새 URI로 리디렉션하라.
    • -지금까지는 getUser같이 동사를 사용해서 URI를 표현하지만 이제는 그냥 명사복수형을 사용하여 표현하라. -> users
•  Methods
  • GET, POST, PUT, DELETE
  • OPTIONS
    • Server가 자신이 처리할 수 있는 operation이 뭔지 알려준다.
  • Head
    • 바디 없이 해드만 보내고 싶을 때
      - 해더 정보만 가져오는 경우?
      새로고침을 했을 때 다시 정보를 불러오기전에 정보가 새로 바뀌었는지 확인하고 바뀌었을 때만 불러오는 경우에 사용
      - 트래픽이나 데이터 절약을 하기 위해서 사용

• Statelessness
  
  • 클라이언트가 너무 많기 때문에 클라이언트의 상태를 서버에서 모두 저장하지 않는다. 
    -> 클라이언트쪽에 쿠키로 저장해놓는다.
  • ex) naver에 접속하면 클라이언트와 서버사이에 세션이 만들어지고 세션아이디는 서버쪽에서 가지고 있는 것이 아니라 클라이언트가 세션 아이디를 가지고 있다(쿠키). 
    서버와 통신을 다시 하고 싶다면 클라이언트가 세션아이디를 보내서 서버와 통신할 수 있다, 
  • 서버는 확장성을 고려해서 설계를 해야한다. 
    => 확장이 가능하려면 이러한 Statelessness를 잘 유지해야한다.
  • 각각의 요청은 독립적으로 생각하기 때문에 서버가 1, 2, 3이 있다면 어느 서버로 요청이 가든지 상관없다. => 만약 클라이언트의 status를 유지하고 있다면 한 서버에만 요청을 해야한다. 
    But status를 서버가 가지고 있지 않기 때문에 다른 서버에도 요청을 할 수 있다. 
    (HTTP 프로토콜가 이러한 statelessness 특징을 가지고 있다.) 
• Caching
  • 정보를 수정했는데 수정한게 넘어오지 않고 예전 정보만 넘어오는 경우 
    -> caching 때문
  • 클라이언트와 서버 사이에는 몇몇 과정이 존재하여 그 과정을 거쳐온다.
    ex) CDN이라는 부분에서 server에 있는 jsp를 caching 해 놓아 클라이언트가 요청하면 서버까지 가지않고 바로 jsp 정보를 넘겨주어 서버에서 jsp를 수정하여도 클라이언트는 그 수정된 jsp 정보를 얻지 못한다. => 따라서 caching 전략을 잘 짜야한다.(장점 : 트래픽과 응답시간이 줄어든다.) 
    => caching 전략은 서버가 정한다.
  • 서버쪽 Response Headers안에 cache-control 이라는 부분에서 caching 전략을 짠다. 
    (시간을 지정하든지 저장하지말라고 할 것인지)

 

 

• Cache-Control
  • no-store : 아무도 케싱하지마!
  • no-cache : 항상 재사용은 하되 검증을 해야된다.(케싱은 하되 asset(정보)이 바뀌었는지 확인을 해야한다.)
  • max-age : 유효기간 설정
  • Cacheable by Intermediary : 중간(예를 들어 CDN)에서 케싱 가능한가 

 

 

• Caching 시나리오

 

 

- 웹 서버는 해당 ETag 값 (유효성 검사 토큰)과 함께 리소스의 현재 표현을 return
ETag : 내가 가지고 있는 버전
유효기간이 지나도 변경됐는지 안됐는지 검증해서 안됐으면 그냥 계속 사용할 때 사용
(내가 가지고 있는 버전과 서버가 가지고 있는 버전이 다른지 확인하여 계속사용할지말지를 확인)
(유통기한이 지난 우유를 바로 안버리는 것과 같음)

 

 

- 클라이언트가 동일한 URL 리소스를 다시 검색하려는 경우

1. 먼저 로컬 캐시 버전의 URL이 만료되었는지 확인한다.
2. URL이 만료되지 않은 경우 로컬 캐시 된 리소스를 검색
3. URL이 만료되었다고 판단되면 클라이언트가 서버에 접속하고 "if-None-Match"필드와 함께 이전에 저장된 ETag 사본을 보낸다.
4. 서버는 이제 현재 버전의 리소스에 대한 ETag와 클라이언트의 ETag를 비교할 수 있다.
5. ETag 값이 일치하면 리소스가 변경되지 않았 음을 의미한다.

• Security
  • 사용자가 입력하는 값들을 검증할 필요가 있다.
  • 클라이언트와 서버사이에 세션이 만들기 전에 인증절차와 권한 부여절차가 필요하다.
  • url에 민감한 데이터를 넣으면 안된다.(바디부분에 넣어서 암호화를 해주어야한다.)
  • 어떤 메서드를 지원할지를 결정하고 각각에 메서드에 대해서 제한된 사항만을 제공해야한다.
  • 잘못된 xml또는 json이 있는지 검증이 필요
  • 예외사항을 처리해야한다.
    (만약 에러페이지에 예외사항들이 뜬다면 보안에 취약한 것이다. 예외사항들을 보고 어느 부분이 취약한지 파악이 가능하기 때문이다.) 

 

References

https://www.tutorialspoint.com/restful/restful_messages.htm

RESTful Web Services - Messages - Tutorialspoint

https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching

HTTP 캐싱  |  Web Fundamentals  |  Google Developers