"웹을 지탱하는 기술"을 읽고 재미있는 곳을 골랐어요.

처음 엔지니어로 일한 지 얼마 되지 않아'웹을 지탱하는 기술'을 읽었다.
웹의 입문서로는 2권이지만, 1권이 쓰이지 않았고, 검색어도 상당히 꼬불꼬불하고 재미있는 내용이 많기 때문에 그런 것들을 고르러 갑니다^^.

SOAP 쌍 REST

웹 아키텍처 표준화에 대한 논쟁

REST의 흥행

원래 당시 캘리포니아대 대학원생이었다면 사람이 분석과 연구를 진행해 REST를 명명하고 논문으로 하나의 아키텍처 형태를 제시했다.
REST의 창도자는 대공급업체가 추진하는 SOAP 기초 기술을 부정하고 웹 스타일의 구조 스타일로 REST를 추천했지만 한 연구자와 대공급업체의 정치력 격차가 뚜렷해 목소리가 들리지 않았다.
REST 보급에 동력을 불어넣은 것은 2002년 등장한 아마존 웹 서비스다.
아마존은 인터넷을 통해 자사가 운영하는 책과 다른 상품에 대한 정보를 프로그램에서 얻을 수 있다.당시에는 SOAP 및 REST 형식으로 제공되었습니다.
Amazon의 웹 API는 정보의 유용성과 처리의 단순성 때문에 순식간에 보급되었으나 SOAP 형식과 REST 형식의 이용 비율이 20대 80이라는 보고서에서 SOAP가 REST에 대한 논쟁에 불을 붙였다.

REST를 부정하는 사람들의 주장.

주장 내용은 다음과 같다.
이어 "아마존처럼 안전성이 필요하지 않은 단순한 웹 API에서는 GET URI의 단순한 방식만 활용되고 있다"며 "하지만 기간시스템 등에서 거래와 신뢰성이 필요할 때 REST의 기능이 부족하다"고 덧붙였다.
필자는 결국 의기양양하게'REST는 장난감'w.
'REST는 장난감이다'에 대한 필자의 설명은 다음과 같다.
이 말 뒤에는 웹 API를 만드는 웹 벤처기업 등 기술자, 이전 엔지니어로부터 모멸을 받는다는 뜻이 담겼죠."HTTP와 URI만 골간 시스템을 만들 수 있나요?"이거 장난감 아니야?

REST 우승

하지만 결국 REST가 이겼다.
2004년부터 시작된 웹 2.0개 프로세스에서 Google과 Amazon 등은 REST 형식의 웹 API를 제공하기 시작했습니다.

주요 원인

웹 2.0에서 가장 중요한 것은 버섯 업그레이드

웹 API에서 제공하는 다양한 정보를 조합하여 하나의 응용 방법을 실현

버섯에 간편한 것을 요구하기 때문에 쉽게 조작할 수 있는 REST

를 받아들였다.

SOAP의 실패 요인

필자는 두 개라고 했어요.

복잡성

RPC/분산 객체가 보유한 기술적 문제를 직접 상속하여 더욱 복잡한 사양 그룹이 되었습니다.

공급업체 간 인터페이스 호환성 부족

복잡한 프로토콜 창고

네트워크 인터페이스를 통해 호출되는 비용

정치적 이유

SOAP 및 WS-*의 표준화 작업은 W3C 및 OASIS에서 수행됩니다.
이곳의 표준화 작업은 각 공급업체가 견본을 가져와 차이를 조정하는 형식으로 진행되었다.그러나 많은 공급업체가 SOAP 자체에 기준이 정해지지 않았을 때 설치했기 때문에 같은 SOAP와 WS-*의 해석도 차이가 나고 상호 운용성이 부족하다.
웹의 급속한 성장으로 인해 SOAP의 사용 표준화 이전에 각 회사는 각양각색의 방법을 취했고 각 회사는 본사의 표준을 통과하기 위해 표준화 경쟁이 발생했다.

URL은 변하지 않는 게 좋아요.

링크집을 만들었는데 404가 지나면 안 돼요.
웹 기반을 흔드는 문제야.
"URI는 변하지 않아야 한다. 변하지 않는 URI가 가장 좋은 URI다."

언어의 확장자나 경로에 의존하지 않음

메소드 이름 및 세션 이름 제외

URL은 리소스를 나타내는 명사

sample/people/show/123

쇼는 동사다.이거 필요 없어.

웹의 무상태성

클라이언트 = 브라우저 등

정신적인 결점

비율을 줄이기 어렵다

부하 분산과 여분 등으로 인해 여러 서버를 설치한 경우 서버 간에 응용 상태를 공유해야 하지만 데이터를 동기화하는 비용이 발생할 수 있다
서버는 클라이언트의 응용 상태가 클라이언트 수가 증가함에 따라 어려워진다는 것을 기억한다.이렇게 하면 상태가 완전한 구조에서 고객 수가 증가하면 축소하기 어렵다.한 서버가 클라이언트에 동시에 연결될 수 있는 수량이 제한되어 있기 때문에 여러 대의 서버를 분산시킬 수 있다.이 경우 여러 서버 간의 응용 프로그램 상태를 동기화시켜 모든 서버가 같은 응용 프로그램 상태를 처리할 수 있도록 해야 한다.

무상태 장점

서버가 아닌 클라이언트의 어플리케이션 상태를 무상태로 저장하여 이러한 문제를 해결합니다

.

이렇게 하면 서버가 새로운 요청에 집중할 수 있다

무상태의 결점

성능 저하

서버에 대한 요청이 중복되고 데이터 전송량이 증가

인증 등 서버에 대한 중복 처리

통신 오류 처리

통신 오류 등으로 요청이 중단되었을 때 서버는 이 요청이 받아들여졌는지 알 수 없습니다.
예컨대 주문 상품 처리 도중 차단된 경우다.
모든 상태에서 서버가 주문서를 처리했는지 알 수 있습니다
무상태의 경우 서버가 주문을 처리했는지 모르기 때문에 중복 주문이 된다.

HTTP 메서드

8가지 방법이 있지만 GET, POST가 공통적으로 사용됩니다.
왜냐하면 HTMl 형식으로 지정할 수 있는 방법은 GET, POST이기 때문이다.
HTML 형식으로도method 매개 변수나 X-HTTP-Mthod-Override에서 다른 방법을 사용할 수 있습니다.

각 방법의 성질에 관하여

각 방법은 모두 응등성과 안전성의 성질이 있기 때문에 오용을 방지해야 한다.
웹 서비스와 API에 잘못된 디자인을 하면 이런 방법의 성질이 보호되지 않아 놀랍다.
메서드
응등성
보안
GET ,POST
○
○
PUT,DELETE
○
×
POST
×
×

응등성

어떤 조작을 해도 결과는 같다
PUT와 DELETE는 동등하므로 동일한 리소스를 몇 번 발행해도 동일한 결과를 얻을 수 있도록 설계해야 합니다.

보안

안전성 = 조작 대상의 자원에 부작용이 없다
GET는 부작용이 없기 때문에 GET와 같은 자원 자원을 여러 번 발표해도 자원의 상태는 변하지 않는다.

상태 코드

상태 코드를 적절하게 반납하면 골치 아픈 일이 생길 수 있다.
예를 들어 404의 부분을 200으로 되돌리면 검색엔진의 로봇이 정상적인 페이지를 판단하고 색인 처리를 할 수 있다.

json 정보

JSON = javascript Object Notation

RFC 4627 규정 데이터 기술 언어

자원 표시 중의 하나.

기타 HTML, 마이크로formats, Atom 등도 있지만 그것들보다 가볍다

데이터 형식

배열

["aaa","bbb","ccc"]

문자열

"hello my frined"

숫자.

-22

열등하지 않다

베란다에서 준비했어요.
이른바 literal

null

위쪽과 같다

대상

{ 
    "name" : {
        "first" : "sato"
        "last" : "shira"
    },
    "age" : 22,
    "interests" : ["Laravel",Vue.js"]
}

최후

SOAP와 REST를 지지하는 사람들의 대립 구조에서 필자는 결국 의기양양하고 흥미롭다고 말한다.'REST는 장난감이다'는 강력한 단어다.공급업체들의 정치적 움직임이 SOAP 폐기의 주요 원인 중 하나에 영향을 미쳤다는 점도 흥미롭다.
웹 페이지의 무상태성에 관하여 장과 절에서 많은 것을 배웠다.