'웹을 지탱하는 기술' 4회차 스터디 정리

February 02, 2020

14장 JSON(Javascript Object Notation)

데이터를 기술하기 위한 언어
Javascript기법으로 데이터를 기술할 수 있음

자료형

Object : 이름과 값의 집합
Array : 순서를 가진 값의 집합
String : 이중인용부호(“)로 감싸야함
number : 정수, 부동소수점이 모두 포함
boolean : true, false(소문자)
null

{
  "name": {
    "first": "John",
    "last": "Doe"
  },
  "blog": "http://blog.example.com",
  "age": 34,
  "interests": {"Web", "XML", "REST"}
}

크로스 도메인 통신

Ajax에서 이용하는 XMLHttpRequest라는 JavaScript의 모듈은 보안상의 제한으로 인해, JavaScript 파일을 가져왔던 동일한 서버하고만 통신할 수 있습니다. 불특정 다수의 도메인에 속하는 서버에 엑세스 하는것을 크로스 도메인 통신이라고 합니다.
XMLHttpRequest에서는 크로스 도메인 통신을 할 수 없지만 HTML의 <script>요소를 이용하면 복수의 사이트에서 JavaScript파일을 읽을 수 있습니다.

웹 서비스의 설계

15장 읽기 전용 웹 서비스의 설계

리소스 설계

리소스 : 웹상에 존재하는 이름이 부여된 정보
리소스설계 : 클라이언트와 서버 간 인터페이스의 설계, 즉 웹 서비스와 웹 API의 외부설계입니다. 어떻게 리소스를 분할하고 URI로 이름을 붙이고, 상호 링크를 가지게 할지가 리소스 설계의 핵심
설계 : 시스템을 어떤 구조로 어떻게 개발할 것인지를 검토하고, 그림이나 문서로 남기는 작업
리소스의 설계도 : 리소스의 종류, 리소스의 표현, 리소스의 조작 방법, 리소스와 리소스의 링크 관계

리소스를 설계할 때 가장 중요한 것은 웹 서비스(인간용 인터페이스)와 웹 API(프로그램용 인터페이스)를 나누어 생각하지 않는것.

설계 방법

웹 서비스에서 제공할 데이터를 특정한다
데이터를 리소스로 나눈다
리소스에 URI로 이름을 부여한다
클라이언트에 제공할 리소스의 표현을 설계한다
링크와 폼을 이용해 리소스와 리로스를 연결한다
이벤트와 표준적인 코스를 검토한다
에러에 대해 검토한다

리소스 지향 아키텍처

어드레스 가능성

URI만 있으면 리소스를 한결같이 가리킬 수 있다는 성질. URI의 이 성질이 없다면 접속성과 Uniform인트페이스를 구현할 수 없음.

접속성

리소스를 링크로 접속하여 하나의 어플리케이션을 이루는 성질.

유티폼 인터페이스

HTTP에서는 GET/POST/DELETE가 기본 메서드이지만, 현실의 웹 서비스에서는 대부분이 GET과 POST만으로 꾸려가고 있음

스테이트리스성

Cookie에 의한 세션관리

흥미로운 점

프로그램에서 다루기 쉬운 쪽을 정규 URI로 하는것이 좋다.(1120002가 112-0002보다 낫다)
검색 쿼리를 표현할때는 ‘q’라는 파라미터를 사용한다
리소스 설계는 스킬이며 반드시 몸에 익혀야한다.

16장 쓰기 가능한 웹 서비스의 설계

쓰기 가능한 웹서비스의 어려운점

복수의 사용자가 동시에 쓰기처리를 하는경우
백업한 데이터를 복원할 때처럼 동시에 복수의 리소스를 갱신하는 경우
복수의 처리과정을 반드시 실행하기 위해서는 어떻게 해야하는지

쓰기 가능한 우편번호 서비스의 설계

리소스의 작성

펙토리 리소스 : 리소스를 작성하기 위한 틀별한 리소스(사전 준비)
PUT : 새로 작성하고 싶은 리소스의 URI에 직접 요청. 작성할 리소스의 URI를 클라이언트가 모두 알고 있기 때문에 응답메시지에 Location헤더 미포함
PUT 장점 : POST를 지원할 필요가 없어지기 때문에 서버측 구현이 간단해짐 / 클라이언트가 작성과 변경을 구별할 필요가 없어도 되므로 클라이언트 측의 구현이 간단해짐
PUT 단점 : 클라이언트가 URI구조를 미리 알아야함 / 요청의 외관상으로는 그 조작이 신규 작성인지 갱신인지 구별할 수 없음

리소스의 갱신

기본적으로 PUT으로 수행함 / 일괄갱신은 POST로 수행함
벌크 업데이트 : 리소스 전체를 송신하느 갱신방법 / 클라이언트의 구현이 간단해지는 반면, 전송데이터가 커짐
파셜 업데이트 : 리소스의 일부분만을 송신하는 갱신 방법 / 데이터가 적음

리소스의 삭제

삭제 대상 리소스 아래에 자식 리소스가 존재하는 경우 주의할것

일괄처리

서버 접속횟수를 줄이기 위한 송신 방법.
일괄처리중 에러가 발생하는 경우 트랜잭션화 or 각 리소스에 대한 처리결과를 클라이언트에 전달

트랜잭션

은행계좌에 5만원을 이체한다면, 출금 계좌에서 5만원을 줄이고, 입금 계좌에서는 5만원을 늘려야한다. 이 때, 어느 한쪽이 성공하고 다른 한쪽이 처리에 실패한다면? 양쪽의 처리가 모두 성공하거나 모두 원래대로 돌아가는것
RESTful하게 구현할 때의 핵심은 트랜잭션 리소스이다.

베타제어

복수의 클라이언트가 동시에 하나의 리소스를 편집할 때 경합이 일어나지 않도록 하나의 클라이언트만 제어하게 하는 처리
비관적 잠금 : 리소스 편집을 위한 경합이 결코 발생하지 않도록 하기 위해서 잠금의 권한을 가진 사람 이외에는 편집할 수 없도록 제한하는 방법 / LOCK, UNLOCK메서드 사용
잠금이 끝난 리소스를 편집하기 위해서는 If헤더로 잠금 토큰을 지정해야함. 갱신이 종료되면 클라이언트는 잠금을 해제
낙관적 잠금 : 항상 같은 문서를 여러 사람이 계속 편집하는 경우는 거의 없다는 전제하에서 통상적인 편집 문서를 잠그지 않고 경함이 일어났을 때 대체하는 구조

흥미로운점

될수 있는 한 심플하게 유지한다
막히면 리소스로 돌아가 생각한다 : 검색기능을 구현하는 SEARCH메소드를 HTTP에 추가하는것이 아니라, 검색결과 리소스를 GET한다는 식으로 사고하자
정말 필요하다면 POST로 무엇이든 할 수 있다.

17장 리소스의 설계

리소스 지향 아키텍처 접근방식의 함정

웹 서비스에서 제공할 데이터를 특정하고 데이터를 리소스로 나누는방법을 알 수 없기 때문

관계 모델로부터의 도출

데이터가 가진 계층 구조를 고려하는 것과 톱 레벨 리소스의 존재를 잊지 않는것이 중요하다.

객체지향 모델로부터의 도출

클래스가 가진 메서드를 조작결과 리스트로 변환한다. 이에 따라 클래스가 가진 풍부한 메서드를 HTTP의 한정된 메서드로 치환할 수 있다.
관계모델에 비해 객체지향 모델은 보다 자세한 정보를 포함하고 있다. 개별 클래스로의 조작을 나타내는 메서드도 정의할 수 있기 때문이다.

정보 아키텍처로부터의 도출

정보를 분류했다고 하더라도 그것들이 어떠한 조작을 받아들이고 전체로서 어떠한 하이퍼미디어 시스템을 구성할 것인지 알 수 없기 때문.

결론

리소스를 설계할 때는 웹 서비스와 웹 API를 나누어 생각하지 않는 것이 매우 중요하다.

Park Answer

Find answer in the record

< '그림으로 배우는 네트워크 구조' 1회차 스터디 정리2020-01-31 TIL >