휴식 기초

REST는 백엔드 프로그래밍의 초석이 된 지 오래다.그러나 많은 개발자들이 REST가 무엇인지에 대해 모호한 개념을 가지고 있거나 HTTP와 혼동하는 것 같다.본 논문에서, 나는 REST의 정확한 구성과 HTTP와의 비교를 밝히려고 한다.

왜 쉬어요?
REST는 클라이언트와 서버 간의 관심사를 분리합니다.우리의 REST 노드가 성숙할수록 우리는 신축성이나 결합 문제가 존재하지 않는 상황에서 클라이언트(전단)나 서버(후단)를 개선할 수 있다.

휴식이란 무엇인가?
REST는 대표적인 국가 이전이라는 뜻으로 처음에는 2000년에 시작되었다.그것은 웹 서비스와 시스템 간의 통신을 표준화하는 데 사용되는 특정한 체계 구조 양식이다.REST 웹 서비스가 있다면 REST 표준(즉 RESTful)을 따라야 합니다.
REST는 처음에 SOAP 프로토콜의 대체품으로 인기가 많았다. 왜냐하면 SOAP 프로토콜은 더 긴 수요 집합을 사용해야 하기 때문이다.그러나 REST는 데이터를 전송하기 위해 어떤 프로토콜을 사용하는지 규정하지 않는다는 점에 주의해야 한다.반대로 단점의 체계 구조와 어떻게 명명하는지에 주목하기 때문에 프로토콜이 아닌 소프트웨어 체계 구조/모델로 여겨진다.그럼에도 불구하고 실제로는 HTTP를 REST를 응용하는 go-to 프로토콜로 권장하지만, MQTT와 같은 다른 프로토콜에 적용할 수 있습니다.

REST 적용 방법
불행하게도 REST의 이 부분은 완전히 이해되거나 따르지 않아 HTTP API REST API를 호출했다. REST가 제대로 따르지 않았음에도 불구하고 2008년 Roy T. Fieldingarticle을 보세요. 그는 그곳에서 으르렁거리며 HTTP 기반의 인터페이스 REST API를 호출한 모든 사람에게 실망을 느꼈습니다.
아래의 몇 가지 부분에서 나는 모든 기본 원리를 상세하게 소개할 것이다. 이것은 일반적인 HTTP 단점이 아니라 진정한 REST 단점을 초래할 것이다.

클라이언트 및 서버 분리
REST에서 클라이언트와 서버는 분리되어 있어 클라이언트와 서버 간의 결합을 감소시켰다.그래서 우리는 유연성과 무상태 서버를 얻었다.

무국적
REST는 무상태를 권장합니다. 즉, 서버가 클라이언트의 상태를 유지하지 않습니다.따라서 서버는 사용자의 세션을 추적하지 않습니다.이것은 서버의 어떤 새로운 사례도 이전 세션을 추적할 필요가 없기 때문에 매우 큰 확장성을 가져올 것이다.

캐시
요청이 REST 뒤에 있으면 해당 요청이 캐시 가능한지 자세히 설명해야 합니다.클라이언트와 서버 측의 요청에 캐시를 적용하면 요청 수량을 크게 줄일 수 있다.심지어 일정 기간 동안 요청을 완전히 취소할 수도 있다.

레이어
클라이언트가 서버에 연결되어 있고 에이전트/로드 밸런서와 같은 새로운 층을 도입한 경우 클라이언트나 서버의 행동에 아무런 영향을 주지 않습니다.따라서 우리는 에이전트, 부하 평형기, 방화벽 등을 추가할 수 있어 시스템의 행위에 영향을 주지 않는다.

통합 인터페이스
REST 체계 구조 스타일에는 반드시 통일된 인터페이스가 있어야 하며, 이로써 모든 부분(클라이언트/서버)이 시간의 추이에 따라 서로 독립적으로 변경할 수 있다.클라이언트와 서버 사이에 완전히 통일된 인터페이스를 구축하려면 네 가지 규칙을 따라야 한다.

요청된 자원 표식
자원(단점)은 요청에 표시해야 합니다.예를 들어 URI를 사용합니다.예를 들어, 사용자 리소스의 경우 HTTP URI에서 사용자가 여기에 필요한 것임을 선언해야 합니다https://example.com/users/.
서버 측의 자원은 클라이언트에게 되돌아오는 표시와 분리되어 있다.따라서 이 사용자는 단점일 수 있고 실제로는 백엔드에서 대량의 자원과 실체로 표시할 수 있지만 이것은 클라이언트/백엔드에서 결합된 것이다.

에서
클라이언트가 자원을 받았을 때, 자원을 수정하거나 삭제할 수 있는 충분한 정보가 있습니다.따라서, 만약 전단이 https://example.com/users/ 에서 사용자를 검색한다면, 그것은 간단한 구조를 따라 목록의 모든 사용자를 조종할 수 있으며, 백엔드에서 이러한 변경 사항을 어떻게 요청하는지 물어볼 필요가 없다.
HTTP를 기반으로 한 REST 단점에서 이것은 HTTP 동사를 통해 이루어진다. 예를 들어 GET to retrieve, POST to create a new resource, PUT to create/update a whole resource, PATCH to modify a Party a resource, DELETE to DELETE a resource 등이다.각 사용자 ID를 반환하는 것과 같은 다른 데이터도 함께 제공됩니다.

자기 설명 정보
이것은 응답 메시지가 자신을 묘사해야 하며, 백엔드로 돌아가서 메시지의 의미를 검색할 필요가 없다는 것을 의미한다.예를 들어 파일이 이진 형식으로 되돌아오면 파일의 형식을 설명하는 속성을 추가해야 한다.만약 응답이 JSON 형식이라면, JSON 형식임을 설명하는 속성이 있어야 합니다.
HTTP 기반의 REST APIhttps://example.com/annual-report/에서 응답은 미디어 형식의 헤더가 있어야 한다. 이 헤더 해석이 되돌아오는 blob는 이런 pdfContent-Type: application/pdf이다.
마찬가지로 HTTP에서 응답은 오류든 성공이든 상태 코드가 있어야 한다는 것을 의미한다.예를 들어 200 (정상) 이나 400 (오류 요청) 을 답장합니다.

어플리케이션 상태 엔진인 HATEOAS

HATEOAS는 REST 노드의 URI를 처음 요청할 때 응답에 백엔드에서 제공하는 링크를 포함해서 응답에 사용할 수 있는 모든 자원을 동적으로 발견하도록 요구할 뿐입니다.
이것은 클라이언트와 백엔드 노드가 완전히 결합되어 백엔드 구조와 노드를 변경할 때 더 많은 자유를 얻게 할 것이다.

    {
      "id": 1,
      "name": "Ahmed Abdulaziz",
      "email": "[email protected]",
      "_links": {
          "self": {
              "href": "https://ahmedabdulaziz.com/users/1"
          },
          "report": {
              "href": "https://ahmedabdulaziz.com/users/1/report"
          }
      }
    }

HATEOES는 큰 화제입니다. 저는 미래에 그것에 대해 전문적으로 토론하는 글을 쓸 수 있습니다. 이 글의 간단명료함을 유지하기 위해서 저는 여기서 HATEOES에 대해 토론하지 않을 것입니다.

리처슨 성숙도 모형
이것은 Leonard Richardson이 2008년에 묘사한 성숙도 모델로 응용 프로그램이 REST 규범을 준수하는 정도를 묘사하고 이를 네 가지 단계의 하나로 나눈다.
이 모델은 우리의 단점이 어느 정도 REST 체계 구조 스타일에 부합되는지 보여주기에 매우 적합하기 때문에 우리의 API는 완전히 성숙한 REST API가 아니지만 여전히 REST 단점으로 간주될 수 있음을 설명할 수 있다.이전의HATEOES와 마찬가지로 이것은 매우 긴 주제이다. 나는 장래에 그것에 관한 게시물을 한 편 쓸 수 있지만 지금은 쓰지 않기 때문에 이 게시물은 간단명료해야 한다.