10 년이 지난 후에 OP에서 요청한 것과 같은 것이 REST 아키텍처에서 어떻게 설계 될 수 있는지에 대한 대답이 실제로 없다는 것을 알면 약간 슬프다 고 느끼므로 지금이 작업을 수행해야한다고 생각합니다.
우선, REST는 무엇입니까?! 약어 REST 또는 ReST는 "Representational State Transfer"를 나타내며 특정 표현 형식으로 자원 상태의 교환을 정의합니다. 표현 형식은 협상 된 미디어 유형과 관련이 있습니다. application/html표현 형식 의 경우 브라우저에서 렌더링되는 HTML 형식의 텍스트 컨텐츠 스트림 일 수 있습니다. 일부 스타일 시트 형식을 적용하여 특정 위치에 특정 요소를 배치 한 경우 일 수 있습니다.
REST는 원칙적으로 브라우저뿐만 아니라 모든 종류의 응용 프로그램을 대상으로하지만 우리 모두가 알고있는 탐색 가능한 웹의 일반화입니다. 따라서 설계 상 웹에 적용되는 것과 동일한 개념이 REST 아키텍처에도 적용됩니다. "RESTful"방식으로 무언가를 달성하는 방법과 같은 질문은 웹 페이지에서 무언가를 달성 한 다음 동일한 개념을 응용 프로그램 계층에 적용하는 방법에 대한 대답을 해결합니다.
웹 기반 계산기는 일반적으로 입력 한 데이터를 서버로 보내기 전에 계산할 값을 입력 할 수있는 "페이지"로 시작할 수 있습니다. HTML에서는 일반적으로 HTML <form>요소를 통해 클라이언트에게 설정 가능한 사용 가능한 매개 변수, 요청을 보낼 대상 위치 및 입력 데이터를 보낼 때 적용 할 표현 형식을 알려줍니다. 이것은 다음과 같이 보일 수 있습니다 :
<html>
<head>
...
</head>
<body>
<form action="/../someResource" method="post" enctype="application/x-www-form-urlencoded">
<label for="firstNumber">First number:</label>
<input type="number" id="firstNumber" name="firstNumber"/>
<label for="secondNumber">Second number:</label>
<input type="number" id="secondNumber" name="secondNumber"/>
<input type="submit" value="Add numbers"/>
</form>
</body>
</html>
위의 샘플은 즉 사용자 또는 다른 자동 입력 장치로 채울 수있는 두 개의 입력 필드가 있으며 제출 입력 요소를 호출하면 브라우저가 입력 데이터를 application/x-www-form-urlencoded전송 되는 표현 형식으로 형식화하는 것을 처리합니다. POST이 경우 지정된 HTTP 요청 방법을 통해 언급 된 대상 위치로 우리가 입력하면 1로 firstNumber입력 필드와 2로 secondNumber입력 필드, 브라우저의 표시를 생성 firstNumber=1&secondNumber=2하고, 타깃 리소스에 대한 실제 요구의 본문이 페이로드를 전송.
따라서 서버에 발행 된 원시 HTTP 요청은 다음과 같습니다.
POST /../someResource
Host: www.acme.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 28
Accept: application/html
firstNumber=1&secondNumber=2
요청이 클라이언트가이 형식을 이해하고 있음을 나타내면 서버는 계산을 수행하고 계산 결과를 포함하는 추가 HTML 페이지로 응답 할 수 있습니다.
Breton이 이미 지적했듯이 "RESTful"URL 또는 URI는 없습니다. URI / URL은 고유 한 것이므로 클라이언트 / 사용자에게 의미를 전달해서는 안됩니다. 위의 계산기 샘플에서 사용자는 데이터를 어디로 보낼지 관심이 없으며 제출 입력 필드를 트리거 할 때 요청이 전송되는 것에 관심이 있습니다. 작업을 수행하는 데 필요한 모든 필수 정보는 이미 서버에서 제공해야합니다.
브라우저는 요청에 실제로 입력 매개 변수가있는 계산기를 먹이고 있음을 알지 못할 수도 있으며 주문 프로세스를 계속하기 위해 다음 양식 표현 만 반환하는 완전히 다른 일종의 주문 양식 일 수도 있습니다. 자원. 이 경우 HTML 사양에서 요구하는 것을 단순히 수행하며 서버가 실제로 수행하는 것을 덜 신경 쓰지 않았습니다. 이 개념을 통해 브라우저는 동일한 표현 형식을 사용하여 선호하는 온라인 상점에서 물건을 주문하고, 가장 친한 친구와 채팅하고, 온라인 계정에 로그인하는 등 모든 종류의 작업을 수행 할 수 있습니다.
일반적으로 버튼으로 렌더링되는 제출 입력 필드 사례에서 특정 요소 의 여유 는 해당 요소와 관련하여 수행해야 할 작업을 정의합니다. 버튼이나 링크의 경우 기본적으로 클릭하라는 메시지가 표시됩니다. 다른 요소는 다른 여유를 전달할 수 있습니다. 이러한 어포던스는 또한 링크 관계 를 통해 표현 될 수있다. 즉 preload, 사용자가이 컨텐츠를 다음에 잡을 가능성이 높기 때문에 클라이언트가 백그라운드에서 링크 된 자원의 컨텐츠를 이미로드 할 수 있음을 클라이언트에게 알리는 주석이 달린 링크를 통해 표현 될 수있다 . 이러한 링크 관계는 물론 표준화되어야하거나 웹 링크에 의해 정의 된 관계 유형에 대한 확장 메커니즘을 따라야합니다 .
이것들은 웹에서 사용되는 기본 개념이며 REST 아키텍처에서도 사용해야합니다. "Uncle Bob"Robert C. Martin에 따르면 아키텍처는 의도에 관한 것이며 REST 아키텍처의 의도는 서버를 클라이언트와 분리하여 서버가 클라이언트를 해치지 않을까 염려하지 않고 미래에 자유롭게 진화 할 수 있도록하는 것입니다. 불행히도 커플 링을 도입하거나 빠른 수정 솔루션을 추가하여 작업을 완료하고 진행하기가 쉽기 때문에 많은 훈련이 필요합니다. Jim Webber가 REST 아키텍처에서 지적한 것처럼 서비스 제공 업체 는 클라이언트가 프로세스가 끝날 때까지 따라야 하는 70 년대의 텍스트 기반 컴퓨터 게임과 유사한 도메인 응용 프로그램 프로토콜 을 설계해야 합니다.
불행히도 실제로 "REST"API가 많이하는 것은 그 밖의 모든 것입니다. 일반적으로 동적으로 즉시 통합하기 어려운 API 관련 외부 문서에 지정된 대부분 JSON 기반 데이터의 교환을 볼 수 있습니다. 요청이 어떻게 보이는지에 대한 형식은 외부 문서에 하드 코딩되어 미리 정의 된 유형 을 반환 하도록 URI를 해석하는 많은 구현으로 이어집니다.사전 협상 된 일반적인 표현 형식을 사용하는 대신. 클라이언트가 이제 미리 정의 된 URI에 대해 특정 데이터 형식 (표현 형식이 아님)을 수신 할 것으로 예상하므로 서버가 변경되지 않습니다. 이 맞춤 데이터 형식 교환은 "데이터 형식"이 일반적으로 특정 API를 지원하기 때문에 클라이언트가 다른 API와 상호 작용하는 것을 방지합니다. 우리는 Peppol이 최근에 AS2를 기본 전송 프로토콜로 AS4로 대체하여 다시 옮겼지만 Corba, RMI 또는 SOAP와 같은 RPC 기술을 통해 과거 부터이 개념을 알고 있습니다.
실제 질문과 관련하여 데이터를 csv 파일로 보내는 것은 application/x-www-form-urlencoded표현이나 유사한 것을 사용 하는 것과 다르지 않습니다 . Jim Webber는 모든 HTTP가 애플리케이션 도메인이 웹을 통해 문서를 전송하는 전송 프로토콜 일뿐 임을 분명히했다 . 클라이언트와 서버는 RFC 7111에text/csv 정의 된 대로 둘 다 지원해야합니다 . 이 CSV 파일은 구성 요소 업로드를 수행하기 위해 HTTP 메소드뿐만 아니라 양식 요소, 대상 요소 또는 요청을 보내는 속성을 정의하는 매체 유형을 처리 한 결과 생성 될 수 있습니다.
HTML , HAL Forms , halform , ion 또는 Hydra 와 같은 양식을 지원하는 두 가지 미디어 유형이 있습니다. 그러나 현재 입력 데이터를 text/csv직접 자동으로 인코딩 할 수있는 미디어 유형을 알지 못 하므로 IANA의 미디어 유형 registry에 정의하고 등록해야 할 수도 있습니다 .
전체 매개 변수 세트의 업로드 및 다운로드는 문제가되지 않아야합니다. 앞에서 언급했듯이 클라이언트가 처리 할 새 컨텐츠를 검색하기 위해 URI를 사용하기 때문에 대상 URI는 관련이 없습니다. 영업일 기준으로 필터링하는 것도 어렵지 않아야합니다. 그러나 여기서 서버는 클라이언트가 단순히 선택할 수있는 모든 가능성을 가진 클라이언트 여야합니다. 최근 몇 년간 GraphQL과 RestQL이 진화하여 필터링 된 응답을 얻기 위해 특정 엔드 포인트를 대상으로하는 SQL과 같은 언어를 도입했습니다. 그러나 진정한 REST 의미에서 이는 REST 뒤에있는 아이디어를 위반합니다. 자원의 기본 데이터 모델.
특정 구성 매개 변수를 활성화하거나 비활성화하는 것은 이러한 여유를 제공하는 하이퍼 미디어 제어를 트리거하는 것입니다. HTML 양식에서 이것은 간단한 확인란이거나 목록 또는 해당 종류의 여러 줄로 선택 될 수 있습니다. 양식과 정의한 방법에 따라 전체 구성을 전송 PUT하거나 변경 사항에 대해 현명하게 할 수 있으며를 통해 부분 업데이트 만 수행 할 수 PATCH있습니다. 후자는 기본적으로 변경 된 표현의 계산을 업데이트 된 것으로 계산하고 현재 표현을 원하는 것으로 변환하는 데 필요한 단계를 서버에 공급합니다. PATH 스펙 에 따르면, 모든 단계가 적용되거나 전혀 적용되지 않도록 트랜잭션 내에서 수행해야합니다.
HTTP는 변경 사항을 적용하기 전에 서버가 수신 된 요청을 미리 검증하도록 허용하고 권장합니다. 들어 PUT 사양 상태 :
오리진 서버는 PUT 표현이 PUT에 의해 변경 될 수 있거나 변경되지 않을 대상 자원에 대한 서버의 제한 조건과 일치하는지 확인해야합니다. 이는 오리진 서버가 GET 응답에서 표시 메타 데이터의 값을 설정하기 위해 URI와 관련된 내부 구성 정보를 사용할 때 특히 중요합니다. PUT 표현이 목표 자원과 일치하지 않는 경우, 원 서버는 표현을 변환하거나 자원 구성을 변경하여 일관성을 유지하거나 표현이 부적합한 이유를 설명하기에 충분한 정보가 포함 된 적절한 오류 메시지로 응답해야한다. 409 (충돌) 또는 415 (지원되지 않는 미디어 유형) 상태 코드가 제안됩니다.
예를 들어, 대상 자원이 항상 "text / html"의 Content-Type을 갖도록 구성되고 PUT 인 표현이 "image / jpeg"의 Content-Type을 갖는 경우, 오리진 서버는 다음 중 하나를 수행해야합니다.
ㅏ. 새 매체 유형을 반영하도록 대상 자원을 재구성하십시오.
비. PUT 표현을 새로운 자원 상태로 저장하기 전에 자원의 형식과 일치하는 형식으로 변환합니다. 또는,
씨. 대상 리소스가 "text / html"로 제한됨을 나타내는 415 (지원되지 않는 미디어 유형) 응답으로 요청을 거부합니다. 새 표현에 적합한 다른 리소스에 대한 링크를 포함 할 수도 있습니다.
HTTP는 PUT 메소드가 사용자 에이전트 요청의 의도와 오리진 서버 응답의 의미로 표현할 수있는 것 이상으로 오리진 서버의 상태에 미치는 영향을 정확히 정의하지 않습니다. ...
이 게시물을 요약하려면 클라이언트에게 필수 또는 지원되는 입력 매개 변수, 요청을 보낼 대상 위치, 사용할 조작 및 매체 유형에 대해 알려줄 수있는 기존 매체 유형을 사용해야합니다. 요청을 형식화하거나 IANA에 등록한 고유 한 요청을 정의해야합니다. 입력을 다음으로 변환하려는 경우 후자가 필요할 수 있습니다.text/csv그런 다음 CSV 표현을 서버에 업로드하십시오. 변경 사항이 리소스에 적용되기 전에 유효성 검사가 수행되어야합니다. 실제 URI는 요청을 어디로 보낼 것인지를 결정하는 것 이외의 클라이언트와 관련이 없어야하며, 따라서 서비스 구현자가 자유롭게 선택할 수 있습니다. 이 단계를 수행하면 언제든지 서버 측을 자유롭게 변경할 수 있으며 사용 된 미디어 유형을 지원하는 클라이언트는 결과적으로 중단되지 않습니다.