REST 및 HTTP 의미론

Roy Fielding은 박사 학위 논문으로 REST를 만들었습니다. 

읽고 나면 세 가지 기본 요소로 요약됩니다.

1. 객체 통계를 설명하는 문서

2. 시스템 간에 객체 상태를 앞뒤로 전송하는 전송 메커니즘

3. 상태에 대해 수행할 작업 집합

로이는 HTTP에만 집중했는데 왜 다른 전송을 사용할 수 없는지 모르겠습니다. 다음은 몇 가지 예입니다.

• WebDAV 공유를 마운트합니다(WebDAV는 HTTP 확장이므로 여전히 HTTP를 사용합니다). 스프레드시트(.xls, .xlsx, .csv, .ods)를 마운트된 폴더에 복사합니다. 여기서 각 행은 신규/업데이트 상태입니다. 공유에 복사하는 행위는 upserting 작업을 나타내고, 파일 이름은 데이터 유형을 나타내며, 열은 필드입니다. 서버는 (문서 이름)-status.(문서 접미사)로 응답하며, 이는 각 행에 대한 키, 상태 및 오류 메시지를 제공합니다. 이 경우 데이터를 요청한다는 것은 실제로 의미가 없습니다.

• gRPC를 사용하세요. 전송되는 객체는 문서이고, HTTP는 전송이며, 원격 메소드의 이름은 작업입니다. 데이터 제공 및 요청이 모두 가능합니다.

• FTP를 사용하세요. WebDAV와 유사하며 파일 기반입니다. PUT 명령은 upsert 중이고 GET 명령은 요청 중입니다. GET은 파일 이름만 제공하므로 일반적으로 지정된 유형의 모든 데이터를 제공합니다. 데이터의 하위 집합을 가져오기 위해 하드 코딩된 필터를 나타내는 특수 파일 이름을 허용할 수 있습니다.

실제 REST 구현을 볼 때마다 기본 HTTP를 따르지 않는 경우가 많습니다. 의미론적으로, 나는 이것에 대해 어떤 설명도 본 적이 없으며 단지 다양한 의견이 있을 뿐입니다. 내가 찾은 것 중 어느 것도 RFC를 참조하지 않았습니다. 대부분은 다음과 같이 생각하는 것 같습니다.

• POST = 만들기

• PUT = 전체 문서 업데이트

• PATCH = 문서의 일부 업데이트

• GET = 전체 문서 검색

이는 POST 및 PUT과 관련하여 HTTP에서 명시한 내용과 반대됩니다. :

• PUT은 '만들기' 또는 '업데이트'입니다. GET은 일반적으로 마지막 PUT을 반환합니다. PUT이 생성되면 201 Created를 반환해야 합니다. PUT이 업데이트되면 200 OK 또는 204 콘텐츠 없음을 반환해야 합니다. RFC는 PUT의 200 OK에 대한 콘텐츠가 작업 상태여야 한다고 제안합니다. SQL의 경우 select 문에서 새 행을 반환해도 괜찮을 것 같습니다. 이는 생성된 모든 열이 별도의 GET을 수행하지 않고도 호출자에게 반환된다는 장점이 있습니다.

• POST는 자체 의미에 따라 리소스를 처리합니다. 이전 RFC에서는 POST가 리소스의 하위 항목을 위한 것이라고 말했습니다. 모든 버전에서는 메일링 리스트에 기사를 게시하는 예를 제공합니다. 모든 버전에서는 리소스가 생성되면 201 Created가 반환되어야 한다고 말합니다.

POST의 실제 의미는 다음과 같습니다.

• 생성, 전체/부분 업데이트 또는 삭제를 제외한 모든 데이터 조작

• 다음과 같이 데이터 조작이 아닌 모든 작업:

• 구문과 일치하는 행에 대한 전체 텍스트 검색.

• 지도에 표시할 GIS 객체를 생성합니다.

단어는 반드시 구현은 명시된 대로 수행하는 경우에만 HTTP를 준수합니다. 업데이트에만 PUT을 사용하면 RFC를 준수하지 않기 때문에 아무 문제도 발생하지 않습니다. 데이터 송수신의 모든 세부 사항을 처리하는 클라이언트를 제공하면 클라이언트 사용자에게는 어떤 동사가 사용되는지는 그다지 중요하지 않습니다.

저는 이유를 원하는 사람입니다. RFC를 따르지 않습니다. 나는 웹 앱에서보다 REST API에서 생성과 업데이트를 분리하는 것의 중요성을 결코 이해하지 못했습니다. 캘린더 약속, 메모, 연락처 등과 같은 휴대폰 앱을 생각해 보세요.

• "만들기"가 더하기 아이콘을 누르면 비어 있거나 기본값이 있는 새 양식이 표시됩니다.

• "업데이트"는 개체를 선택하고 현재 값이 포함된 입력 양식을 표시하는 연필 아이콘을 누르는 것입니다.

• 입력 양식이 나타나면 필드 유효성 검사 측면에서 정확히 동일하게 작동합니다.

그렇다면 REST API와 웹 프런트 엔드가 휴대폰 앱과 왜 달라야 할까요? 전화 사용자가 '만들기'와 '업데이트'에 대해 동일한 데이터 입력 양식을 얻는 것이 도움이 된다면 API 및 웹 사용자에게도 도움이 되지 않을까요?

PUT을 다음과 같이 사용하기로 결정했다면 "만들기" 또는 "업데이트"를 수행하고 SQL을 저장소로 사용하는 경우 대부분의 공급업체는 일종의 upsert 쿼리를 사용합니다. 안타깝게도 이는 200 OK 또는 201 Created를 언제 반환할지 결정하는 데 도움이 되지 않습니다. upsert에 대한 삽입과 업데이트를 구별하거나 다른 쿼리 전략을 사용하는 방법을 찾으려면 DML 쿼리가 실행될 때 드라이버가 제공하는 정보를 살펴봐야 합니다. 

간단한 예는 업데이트 세트를 수행하는 것입니다. 여기서 pk 열 = pk 값입니다. 한 행이 영향을 받은 경우 해당 행이 존재하고 업데이트된 것입니다. 그렇지 않으면 행이 존재하지 않으며 삽입이 필요합니다. Postgres에서는 다음과 같이 행 데이터뿐만 아니라 실제로 무엇이든 반환할 수 있는 RETURNING 절을 활용할 수 있습니다.

SQL VALUES (...) ON CONFLICT() DO UPDATE SET ( ...) 반환 중(SELECT COUNT() FROMWHERE=)이 존재합니다." data-lang="text/x-sql" style="box-sizing: border-box;">1

INSERT INTO <table>
VALUES (...)
ON CONFLICT(<pk column>) DO
UPDATE SET (...)
RETURNING (SELECT COUNT(<pk column>) FROM <table> WHERE <pk column> = <pk value>) exists

이것의 천재성은

• RETURNING 절의 하위 선택이 먼저 실행되므로 INSERT ON CONFLICT UPDATE 쿼리가 실행되기 전에 행이 존재하는지 확인합니다. 쿼리 결과는 "exists"라는 열 하나입니다. 해당 행이 쿼리 전에 존재했다면 1이 됩니다. 실행되지 않은 경우 0.

• RETURNING 절은 제공되지 않았지만 생성된 항목을 포함하여 행의 열을 반환할 수도 있습니다.

삽입 또는 업데이트가 필요한 경우 처리하는 방법을 한 번만 파악하고 모든 PUT에서 200 OK 또는 201 Created를 처리하도록 호출할 수 있는 간단한 추상화를 만들면 됩니다.

사용하면 좋은 이점 중 하나 PUT의 의도는 POST를 보는 순간 그것이 검색이나 지속성이 아니라는 것을 확실히 알 수 있도록 하고, 반대로 검색이나 지속성이 아닌 작업에 대한 코드를 찾으려면 POST를 검색해야 한다는 것입니다.

RFC에 설명된 대로 PUT 및 POST를 사용하면 사람들이 RFC를 준수하지 않는 방식으로 사용하는 이유보다 더 큰 이점이 있다고 생각합니다.

위 내용은 REST 및 HTTP 의미론의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!