http - 차이 - rest api 예제




REST에서 PUT 대 POST (20)

오리진 서버는 해당 URI로 자원을 작성할 수 있습니다

따라서 POST를 사용하고 아마도 자원 생성을 위해 PUT을 사용할 필요는 없습니다. 둘 다 지원할 필요는 없습니다. 나를 위해 POST 완벽하게 충분하다. 따라서 설계 결정입니다.

인용 된 인용문에서 PUT을 사용하여 IRI에 할당 된 리소스가 없으며 어쨌든 리소스를 만들려고합니다. 예를 들어, PUT /users/123/password일반적으로 이전 암호를 새 암호로 바꿉니다. 암호가없는 경우 암호를 만들 수 있습니다 (예 : 새로 등록한 사용자 또는 금지 된 사용자 복원).

HTTP / 1.1 스펙에 따르면 :

POST 메소드는 원 서버가 요청에 포함 된 엔티티를 Request-URIRequest-URI 에 의해 식별 된 자원의 새로운 하위 노드로 수락하도록 요청하는 데 사용됩니다

즉, POST생성 하는 데 사용됩니다.

PUT 메서드는 동봉 된 엔터티가 제공된 Request-URI 아래에 저장되도록 Request-URI . Request-URI 가 이미 존재하는 자원을 가리키는 경우, 동봉 된 엔터티는 원래 서버에 상주하는 엔터티의 수정 된 버전으로 간주되어야한다 (SHOULD). Request-URI 가 기존 자원을 가리 키지 않고 해당 URI가 요청 사용자 에이전트에 의해 새 자원으로 정의 될 수있는 경우 원 서버는 해당 URI로 자원을 작성할 수 있습니다. "

PUT생성 또는 업데이트 하는 데 사용됩니다.

그렇다면 리소스를 생성하기 위해 어느 것을 사용해야합니까? 아니면 둘 모두를 지원해야합니까?


개요:

몹시 떠들어 대다:

다음과 같은 방법으로 PUT 또는 POST로 수행 할 수 있습니다.

놓다

newResourceId 를 식별자로 사용하거나 / resources URI 또는 컬렉션 아래에 새 리소스를 만듭니다.

PUT /resources/<newResourceId> HTTP/1.1 

우편

/ resources URI 또는 콜렉션 아래에 새 자원을 작성합니다. 일반적으로 식별자는 서버에 의해 반환됩니다.

POST /resources HTTP/1.1

최신 정보:

다음과 같은 방법으로 PUT으로 수행 할 있습니다.

놓다

/ resources URI 또는 컬렉션 아래의 식별자로 existingResourceId 를 사용하여 리소스를 업데이트합니다.

PUT /resources/<existingResourceId> HTTP/1.1

설명:

일반적으로 REST와 URI를 처리 할 때는 왼쪽에 제네릭 이 있고 오른쪽고유 한 URI가 있습니다 . 제네릭 은 일반적으로 콜렉션 이라고하며보다 구체적인 항목은 리소스 라고 할 수 있습니다. 리소스 에는 컬렉션 이 포함될 수 있습니다.

예 :

<- 제네릭 특정 ->

URI: website.com/users/john
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource

URI:website.com/users/john/posts/23
website.com  - whole site
users        - collection of users
john         - item of the collection, or a resource
posts        - collection of posts from john
23           - post from john with identifier 23, also a resource

POST를 사용할 때 항상 콜렉션을 참조하므로 다음과 같이 말할 때마다 :

POST /users HTTP/1.1

사용자 컬렉션에 새 사용자를 게시하고 있습니다 .

계속해서 다음과 같은 것을 시도해보십시오.

POST /users/john HTTP/1.1

작동하지만 의미 론적으로 사용자 컬렉션 아래의 john 컬렉션 에 리소스를 추가하려고한다고 말하고 있습니다 .

PUT을 사용하면 리소스 또는 단일 항목을 참조 할 수 있습니다. 그래서 당신이 말할 때 :

PUT /users/john HTTP/1.1

당신은 서버 업데이트에게 알려주거나 존재하지 않는 경우 사용자 컬렉션 아래의 john 리소스 를 생성합니다.

투기:

몇 가지 중요한 부분을 강조하겠습니다.

우편

POST 메소드는 원 서버가 요청에 포함 된 엔티티를 Request-URI의 Request-URI에 의해 식별 된 자원의 새로운 하위 노드수락 하도록 요청하는 데 사용됩니다

따라서 컬렉션 에 새 리소스 를 만듭니다.

놓다

PUT 메서드는 동봉 된 엔터티가 제공된 Request-URI 아래에 저장 되도록 요청합니다. Request-URI가 이미 존재하는 자원을 가리키는 경우, 동봉 된 엔터티는 원래 서버에 상주하는 엔터티의 수정 된 버전 으로 간주되어야한다 (SHOULD). Request-URI가 기존 자원을 가리 키지 않고 해당 URI가 요청 사용자 에이전트에 의해 자원 으로 정의 될 수있는 경우 원 서버는 해당 URI로 자원을 작성할있습니다 . "

따라서 자원의 존재를 기반으로 작성 또는 갱신하십시오.

참고:


REST는 매우 높은 수준의 개념입니다. 사실, 그것은 HTTP를 전혀 언급하지 않습니다!

HTTP에서 REST를 구현하는 방법에 대해 의문이 있으면 언제든지 Atom Publication Protocol (AtomPub) 스펙을 살펴볼 수 있습니다. AtomPub은 REST의 발명가이자 HTTP의 (공동) 발명가 인 Roy Fielding의 의견을 수렴하여 HTTP 및 REST의 많은 유명 인사가 개발 한 HTTP를 사용하여 RESTful 웹 서비스를 작성하기위한 표준입니다.

사실 AtomPub을 직접 사용할 수도 있습니다. 블로깅 커뮤니티에서 나온 것은 사실이지만 블로깅에 국한되지는 않습니다. 이는 HTTP를 통해 임의의 자원을 임의로 (중첩 된) 콜렉션과 RESTfully 상호 작용하기위한 일반 프로토콜입니다. 응용 프로그램을 중첩 된 자원 콜렉션으로 표현할 수 있다면 AtomPub을 사용할 수 있으며 PUT 또는 POST 사용 여부, 리턴 할 HTTP 상태 코드 및 모든 세부 사항을 신경 쓸 필요가 없습니다.

AtomPub은 리소스 생성에 대해 다음과 같이 말합니다 (9.2 절).

컬렉션에 멤버를 추가하기 위해 클라이언트는 POST 요청을 컬렉션의 URI로 보냅니다.


간단히 말해서 :

PUT 은 멱등수입니다. 동일한 작업이 한 번 또는 여러 번 실행되는 경우 리소스 상태는 동일합니다.

POST 는 멱등수가 아니기 때문에 한 번 실행하는 것과 비교하여 여러 번 실행하면 리소스 상태가 달라질 수 있습니다.

데이터베이스 쿼리와 유추

PUT "UPDATE STUDENT SET address ="abc "와 같이 생각할 수 있습니다. 여기서 id ="123 ";

POST "INSERT INTO STUDENT (name, address) VALUES ("abc ","xyzzz ")와 같은 것을 생각할 수 있습니다.

학생 ID가 자동 생성됩니다.

PUT을 사용하여 동일한 쿼리가 여러 번 또는 한 번 실행되면 STUDENT 테이블 상태는 동일하게 유지됩니다.

POST의 경우 동일한 쿼리가 여러 번 실행되면 여러 개의 Student 레코드가 데이터베이스에 만들어지고 "INSERT"쿼리를 실행할 때마다 데이터베이스 상태가 변경됩니다.

참고 : PUT에는 업데이트가 필요한 리소스 위치 (이미 리소스)가 필요하지만 POST에는 필요하지 않습니다. 따라서 POST는 직관적으로 새로운 리소스 생성을 의미하지만 PUT은 이미 존재하는 리소스를 업데이트하는 데 필요합니다.

일부는 POST로 업데이트를 수행 할 수 있다고 생각할 수도 있습니다. 업데이트에 사용할 규칙이나 만들 때 사용할 규칙은 없습니다. 다시 이것은 관례이며, 직관적으로 나는 위에서 언급 한 추론에 관심을 갖고 그것을 따르고있다.


생성하려면 POST를 사용하고 업데이트하려면 PUT을 사용하십시오. Ruby on Rails가 그렇게하고 있습니다.

PUT    /items/1      #=> update
POST   /items        #=> create

웹에서 주장하는 어설 션을 찾을 수 있습니다.

어느 쪽도 옳지 않습니다.

액션의 idempotence 을 기반으로 PUT과 POST 중 하나를 선택하는 것이 좋습니다.

PUT 은 리소스를 넣는 것을 의미합니다. 주어진 URL에서 사용 가능한 모든 것을 완전히 다른 것으로 대체합니다. 정의상 PUT은 멱등수입니다. 원하는만큼 여러 번 해보십시오. 결과는 같습니다. x=5 는 멱등수입니다. 이전에 존재했는지 여부에 상관없이 리소스를 PUT 할 수 있습니다 (예 : Create 또는 Update).

POST 가 자원을 업데이트하거나 보조 자원을 추가하거나 변경합니다. POST는 멱등수가 아닙니다. x++ 는 멱등수가 아닙니다.

이 인수에 의해 PUT은 생성 할 URL을 알고있을 때 생성합니다. POST를 사용하면 만들려는 항목의 카테고리에 대한 "공장"또는 관리자의 URL을 알고있을 때 생성 할 수 있습니다.

그래서:

POST /expense-report

또는:

PUT  /expense-report/10929

사무용 겉옷:

PUT 및 POST를 모두 사용하여 생성 할 수 있습니다.

당신은 "당신이 행동을 수행하고있는 것은 무엇입니까?" 당신이 사용해야 할 것을 구분할 수 있습니다. 질문을하기위한 API를 설계한다고 가정 해 보겠습니다. POST를 사용하려면 질문 목록을 사용하십시오. PUT을 사용하고 싶다면 특정 질문을 할 것입니다.

위대한 두 가지 모두 사용할 수 있으므로 어느 것을 RESTful 디자인에 사용해야합니까?

PUT과 POST를 모두 지원할 필요는 없습니다.

사용되는 것은 당신에게 달려 있습니다. 그러나 요청에서 참조하는 개체에 따라 올바른 개체를 사용해야합니다.

몇 가지 고려 사항 :

  • 명시 적으로 생성 한 URL 객체의 이름을 지정 하시겠습니까? 아니면 서버가 결정하도록 하시겠습니까? 이름을 정하면 PUT을 사용하십시오. 서버가 POST를 사용하도록 결정한 경우 POST를 사용하십시오.
  • PUT은 멱등수이므로, 오브젝트를 두 번 PUT하면 효과가 없습니다. 이것은 훌륭한 속성이므로 가능한 경우 PUT을 사용합니다.
  • 동일한 개체 URL로 PUT을 사용하여 리소스를 업데이트하거나 만들 수 있습니다.
  • POST를 사용하면 URL에 수정을가하면서 동시에 2 개의 요청을받을 수 있으며 객체의 다른 부분을 업데이트 할 수 있습니다.

예 :

나는 이것에 관한 또 다른 대답의 일부로 다음을 썼다 :

우편:

리소스 수정 및 업데이트에 사용됩니다.

POST /questions/<existing_question> HTTP/1.1
Host: www.example.com/

다음은 오류입니다.

POST /questions/<new_question> HTTP/1.1
Host: www.example.com/

URL이 아직 작성되지 않은 경우 이름을 지정하는 동안 POST를 사용하여 URL을 작성하지 않아야합니다. <new_question> 이 아직 존재하지 않기 때문에 'resource not found'오류가 발생합니다. 먼저 <new_question> 리소스를 서버에 <new_question> 합니다.

POST를 사용하여 리소스를 만들려면 다음과 같이 할 수 있습니다.

POST /questions HTTP/1.1
Host: www.example.com/

이 경우 자원 이름을 지정하지 않으면 새 오브젝트 URL 경로가 리턴됩니다.

놓다:

리소스를 만들거나 덮어 씁니다. 리소스를 지정하는 동안 새 URL.

새 리소스 :

PUT /questions/<new_question> HTTP/1.1
Host: www.example.com/

기존 자원을 겹쳐 쓰려면 다음을 수행하십시오.

PUT /questions/<existing_question> HTTP/1.1
Host: www.example.com/

새로운 답변 (REST를 더 잘 이해할 수있게 됨) :

PUT은 서비스가 이제부터 클라이언트가 식별 한 자원의 표현을 렌더링하는 데 사용해야하는 컨텐츠에 대한 설명 일뿐입니다. POST는 서비스가 지금부터 어떤 컨텐츠를 포함해야 하는가 (복제 될 수 있는지)에 대한 설명이지만, 서버가 컨텐츠를 식별하는 방법은 서버에 달려 있습니다.

PUT x( resourcex 식별하는 경우 ) : " 내 콘텐츠로 식별되는 리소스의 콘텐츠를 바꿉니다 ."resourcex

PUT x( x리소스를 식별하지 않는 경우 ) : "내 콘텐츠가 포함 된 새 리소스를 만들고 x이를 식별하는 데 사용하십시오."

POST x: "내 콘텐츠를 저장하고 해당 콘텐츠 (다른 콘텐츠와 혼합되었을 수 있음)를 포함하는 자원 (이전 또는 신규)을 식별하는 데 사용할 수있는 식별자를 제공하십시오. 해당 자원은 동일하거나 동일해야합니다 x." " y 의 자원은 x 의 자원에 종속된다 "는 일반적으로 yx (예 : x = /fooy = /foo/bar) 의 하위 경로 로 만들고 x 의 자원 표현을 수정 하여 존재를 반영하도록 예를 들어 y에 대한 하이퍼 링크가있는 새로운 리소스의 자원과 일부 메타 데이터. 후자만이 REST에서 URL이 불투명하기 때문에 훌륭한 디자인에는 필수적 입니다. 클라이언트 측 URL 구성 대신 하이퍼 미디어 를 사용 하여 어쨌든 서비스를 트래버스해야합니다.

REST에는 "content"가 포함 된 리소스가 없습니다. 나는 서비스가 표현을 일관성있게 표현하기 위해 사용하는 데이터에 "컨텐츠"라고 언급한다. 일반적으로 데이터베이스 또는 파일 (예 : 이미지 파일)의 일부 관련 행으로 구성됩니다. 사용자의 컨텐트를 JSON 페이로드를 SQL 문으로 변환하는 것과 같이 서비스에서 사용할 수있는 것으로 변환하는 것은 서비스에 달려 있습니다.

원래의 대답 (읽기 쉬울 수도 있음) :

PUT /something( /something이미 존재하는 경우 ) : "가지고있는 것을 가져 /something가서 내가 주었던 것과 바꾸십시오."

PUT /something( /something아직 존재하지 않는 경우 ) : "내가주는 것을 가져 가서 가져다주세요 /something."

POST /something: "내가 /something끝내면 내 URL을 알려주 는 한, 내가주는 것을 가져 가서 원하는 곳이면 어디든지 둘 수 있습니다 ."


Ruby on Rails 4.0은 PUT 대신 'PATCH'메소드를 사용하여 부분 업데이트를 수행합니다.

RFC 5789는 (1995 년 이후) PATCH에 대해 말합니다 :

상호 운용성을 개선하고 오류를 방지하려면 새로운 방법이 필요합니다. PUT 메서드는 리소스를 완전히 새로운 본문으로 덮어 쓰도록 이미 정의되었으며 부분 변경을 수행하기 위해 다시 사용할 수 없습니다. 그렇지 않으면 프록시와 캐시, 클라이언트와 서버조차도 작업 결과에 대해 혼란 스러울 수 있습니다. POST는 이미 사용되었지만 광범위한 상호 운용성이 없습니다 (패치 형식 지원을 검색하는 표준 방법은 없습니다). PATCH는 이전 HTTP 사양에서 언급되었지만 완전히 정의되지 않았습니다.

" Edge Rails : PATCH는 업데이트를위한 새로운 기본 HTTP 방법입니다 ."에서 설명합니다.


나는 다음과 같이 착륙 할 예정이다.

PUT은 URI로 식별되는 자원을 나타냅니다. 이 경우 업데이트하고 있습니다. 그것은 자원을 언급하는 3 개의 동사의 일부입니다. 삭제하고 다른 두 개의 동사가되는 것입니다.

POST는 기본적으로 자유 형식의 메시지이며, 의미는 '대역 외'로 정의됩니다. 메시지를 디렉토리에 리소스를 추가하는 것으로 해석 할 수 있다면 확인이 가능하지만 기본적으로 보내는 메시지 (게시)를 이해하여 리소스의 발생 상황을 파악해야합니다.

PUT 및 GET 및 DELETE는 자원을 참조하기 때문에 정의에 따라 멱등 원입니다.

POST는 다른 세 가지 기능을 수행 할 수 있지만 요청의 의미는 캐시 및 프록시와 같은 중개자에서 손실됩니다. 이것은 게시물의 URI가 반드시 적용 대상 리소스를 나타내지는 않기 때문에 리소스에 보안을 적용하는 데에도 적용됩니다.

PUT은 생성 일 필요는 없습니다. 자원이 아직 작성되지 않았 으면 서비스에 오류가 _ 생할 수 있지만 그렇지 않으면 갱신하십시오. 또는 그 반대의 경우 - 리소스를 만들지 만 업데이트를 허용하지 않을 수 있습니다. PUT에 대해 요구되는 유일한 것은 그것이 특정 자원을 가리키고 그 유료 하중이 그 자원의 표현이라는 것입니다. 성공적인 PUT은 GET이 동일한 리소스를 검색한다는 것을 의미합니다 (간섭 금지).

편집 : 한 가지 더 - PUT을 만들 수 있지만 ID가 자연 ID (일명 전자 메일 주소) 여야합니다. 그렇게하면 두 번 넣을 때, 두 번째는 첫 번째 업데이트가됩니다. 이것은 그것을 멱등수로 만든다 .

ID가 생성되면 (예 : 새 직원 ID) 동일한 URL을 가진 두 번째 PUT이 멱등 원 규칙을 위반하는 새 레코드를 만듭니다. 이 경우 동사는 POST이고 메시지 (자원 아님)는이 메시지에 정의 된 값을 사용하여 자원을 작성하는 것입니다.


다음은 간단한 규칙입니다.

PUT 을 URL로 사용하여 해당 URL에있는 자원을 업데이트하거나 작성해야합니다.

다른 URL ( "하위") URL에 있거나 HTTP를 통해 찾을 수없는 리소스를 업데이트하거나 만들려면 URL에 대한 POST 를 사용해야합니다.


대부분의 경우 다음과 같이 사용하게됩니다.

  • 컬렉션에 리소스 게시
  • 컬렉션 / : id로 식별되는 리소스를 푸십시오 .

예 :

  • 게시물 / 항목
  • PUT / items / 1234

두 경우 모두 요청 본문에는 자원을 만들거나 업데이트 할 데이터가 들어 있습니다. POST가 멱등수가 아닌 경로 이름에서 분명해야합니다 (3 번 호출하면 3 개의 객체가 생성됩니다). PUT은 멱등수입니다 (3 번 호출하면 결과가 동일합니다). PUT은 "upsert"작업 (생성 또는 업데이트)에 자주 사용되지만 수정할 때만 404 오류를 반환 할 수 있습니다.

POST는 콜렉션에 새 요소를 "생성"하고 PUT은 주어진 URL에서 요소를 "대체"합니다. 그러나 부분 수정에는 PUT을 사용하는 것이 매우 일반적입니다. 즉, 기존 자원을 업데이트하는 데만 사용하고 본문의 포함 된 필드 만 수정하십시오 (다른 필드는 무시). 이는 기술적으로 올바르지 않으므로 REST-purist가 되려면 PUT이 전체 자원을 대체해야하며 부분 업데이트에는 PATCH를 사용해야합니다. 개인적으로 모든 API 끝점에서 동작이 명확하고 일관성있는 한별로 신경 쓰지 않습니다.

REST는 API를 단순하게 유지하기위한 규칙 및 지침 집합임을 기억하십시오. 만약 당신이 단지 "RESTfull"박스를 체크하기 위해 복잡한 일을 끝내면 그 목적을 무너 뜨릴 수 있습니다;)


둘 다 클라이언트에서 서버 사이의 데이터 전송에 사용되지만 그 차이는 다음과 같습니다.

유추:

  • 타고 즉, PUT 넣어 그것을 어디에.
  • 우체국 에서 우편 으로 보내는 POST .


아마도 이것들을 기술하는 불가 지론적인 방법이있을 수 있지만, 웹 사이트에 대한 답변에서 나온 다양한 진술과 상충되는 것처럼 보입니다.

여기서 아주 명확하고 직접하십시오. 웹 API로 작업하는 .NET 개발자 인 경우 사실은 (Microsoft API 설명서에서), http://www.asp.net/web-api/overview/creating-web-apis/creating-a-web-api-that-supports-crud-operations :

1. PUT = UPDATE (/api/products/id)
2. MCSD Exams 2014 -  UPDATE = PUT, there are **NO** multiple answers for that question period.

물론 "POST"를 사용하여 업데이트 할 수 있지만, 주어진 프레임 워크로 사용자를 위해 마련된 규칙을 따르십시오. 필자의 경우 .NET / Web API이므로 PUT은 UPDATE를위한 토론이 아니다.

Amazon 및 Sun / Java 웹 사이트 링크를 통해 모든 의견을 읽는 Microsoft 개발자에게 도움이되기를 바랍니다.


의미는 서로 다른 것으로 가정합니다. 즉, "GET"과 같은 "PUT"은 멱등수 (Idempotent)로되어 있습니다. 즉, 정확히 동일한 PUT 요청을 여러 번 수행 할 수 있으며 결과는 마치 한 번만 실행 한 것과 같습니다.

가장 널리 사용되고 있으며 가장 유용하다고 생각되는 컨벤션을 설명 할 것입니다.

특정 URL에서 자원을 PUT하면 해당 URL이나 그 행에있는 내용이 저장되어야합니다.

특정 URL의 리소스로 POST 할 때 종종 관련 URL을 해당 URL에 게시합니다. 이는 URL의 자원이 이미 있음을 의미합니다.

예를 들어, 새 스트림을 만들려는 경우 일부 URL로 PUT 할 수 있습니다. 그러나 기존 스트림에 메시지를 POST하려면 URL에 POST하십시오.

스트림의 속성을 수정하는 방법은 PUT 또는 POST를 사용하여 수행 할 수 있습니다. 기본적으로, 작업이 멱등수 일 때만 "PUT"을 사용하십시오. 그렇지 않으면 POST를 사용하십시오.

그러나 모든 최신 브라우저가 GET 또는 POST 이외의 HTTP 동사를 지원하는 것은 아닙니다.


POST는 편지를 우편함에 게시하거나 이메일을 이메일 대기열에 게시하는 것과 같습니다. PUT은 큐비 구멍이나 선반에있는 물건 (물건을 알 수있는 주소)을 넣을 때와 같습니다.

POST를 사용하면 QUEUE 또는 COLLECTION의 주소로 게시하고 있습니다. PUT을 사용하면 ITEM의 주소로 이동합니다.

PUT은 멱등수입니다. 요청을 100 번 보낼 수 있으며 중요하지 않습니다. POST는 멱등수가 아닙니다. 요청을 100 번 보내면 우편함에 100 개의 이메일 또는 100 개의 글자가 생깁니다.

일반적인 규칙 : 아이템의 ID 나 이름을 알고 있다면 PUT을 사용하십시오. 항목의 ID 또는 이름을 수신 측에서 지정하려면 POST를 사용하십시오.


가장 중요한 고려 사항은 신뢰성 입니다. POST 메시지가 손실되면 시스템의 상태가 정의되지 않습니다. 자동 복구가 불가능합니다. PUT 메시지의 경우 첫 번째 재 시도가 성공할 때까지 상태가 정의되지 않습니다.

예를 들어, POST로 신용 카드 거래를 생성하는 것은 좋지 않을 수 있습니다.

리소스에 자동 생성 된 URI가있는 경우 생성 된 URI (빈 리소스를 가리키는)를 클라이언트에 전달하여 PUT을 계속 사용할 수 있습니다.

다른 고려 사항 :

  • POST는 포함하는 전체 자원의 캐시 된 사본을 무효화합니다 (보다 일관성있게).
  • PUT 응답은 캐시 가능하지 않지만 POST는 (콘텐츠 필요 및 만료 필요)
  • PUT은 Java ME, 오래된 브라우저, 방화벽 등에서는 덜 지원됩니다.

나는 RFC 2616의 PUT 정의 에서이 조언을 좋아한다 .

POST 요청과 PUT 요청의 근본적인 차이점은 Request-URI의 다른 의미에 반영됩니다. POST 요청의 URI는 동봉 된 엔티티를 처리 할 자원을 식별합니다. 이 리소스는 데이터 수용 프로세스, 다른 프로토콜에 대한 게이트웨이 또는 주석을 허용하는 별도의 엔터티 일 수 있습니다. 반대로 PUT 요청의 URI는 요청과 함께 묶인 엔터티를 식별합니다. 사용자 에이전트는 의도 한 URI를 알고 있으며 서버는 다른 리소스에 요청을 적용하려고 시도해서는 안됩니다.

여기에 다른 조언이 있습니다. PUT은 이미 이름이있는 리소스에 가장 잘 적용되며 POST는 기존 리소스 아래에 새 객체를 만드는 데 유용하며 서버가 이름을 지정하게합니다.

필자는 이것을 PUT에 대한 멱등환 요구 사항을 다음과 같이 해석합니다.

  • POST는 컬렉션 아래에 새 객체를 만드는 데 적합합니다 (그리고 create는 멱등수 일 필요가 없습니다)
  • PUT은 기존 객체를 업데이트하는 데 유용하며 (업데이트는 멱등수가되어야 함)
  • POST는 기존 객체에 대한 멱등 원이 아닌 업데이트 (특히 전체를 지정하지 않고 객체의 일부를 변경하는 경우에도 사용할 수 있습니다. 생각해 보면 컬렉션의 새 멤버를 만드는 것이 실제로 이런 종류의 특수한 경우입니다. 컬렉션의 관점에서 업데이트)
  • 클라이언트가 자원의 이름을 지정할 수있는 경우에만 PUT을 작성에 사용할 수도 있습니다. 그러나 REST 클라이언트는 URL 구조에 대한 가정을하지 않아야하기 때문에 사물의 의도 된 정신이 덜합니다.

이 주제를 처음 접한 독자 는해야 할 일과 경험의 교훈이 상대적으로 부재 한 지에 대한 끊임없는 토론에 충격을 받을 것입니다. REST가 SOAP보다 "선호"되었다는 사실은 경험에서 얻은 높은 수준의 학습이라고 생각합니다.하지만 거기에서 우리가 발전해야만했던 선량은 무엇입니까? 2016 년이야. 로이의 논문은 2000 년이었다. 우리는 무엇을 개발 했는가? 재밌었 어? 통합하기가 쉬웠습니까? 지원 하시겠습니까? 스마트 폰과 비정상적인 모바일 연결의 증가를 처리할까요?

ME에 따르면 실제 네트워크는 신뢰할 수 없습니다. 시간 제한을 요청합니다. 연결이 재설정됩니다. 네트워크는 한 번에 몇 시간 또는 며칠 동안 작동하지 않습니다. 열차는 모바일 사용자가 탑승하는 터널로 이동합니다. 모든 요청에 ​​대해 (때때로이 모든 토론에서 인정 된 것처럼) 요청은 도중에 물에 빠질 수 있으며 응답이 물에 돌아갈 수 있습니다. 이러한 상황에서 PUT, POST 및 DELETE 요청을 실질적인 리소스에 대해 직접 발급하면 항상 저에게 다소 잔인하고 순진 해합니다.

HTTP는 요청 - 응답의 안정적인 완료를 보장하는 데 아무런 역할을하지 않으며 네트워크 인식 응용 프로그램의 작업이기 때문에 괜찮습니다. 그런 응용 프로그램을 개발하면 POST 대신 PUT을 사용하여 농구대를 뛰어 넘을 수 있습니다. 그런 다음 중복 요청을 감지하면 서버에서 특정 종류의 오류를 발생시킬 수 있습니다. 클라이언트로 돌아와서 이러한 오류를 해석하고 다시 가져오고, 다시 유효성을 검사하고 다시 게시하기 위해 농구를 뛰어 넘어야합니다.

또는 안전하지 않은 요청을 일시적인 단일 사용자 리소스로 간주 할 수 있습니다 (작업이라고 부름). 클라이언트는 자원에 대한 POST가 비어있는 실제 자원에 대해 새로운 "조치"를 요청합니다. POST는이 용도로만 사용됩니다. 안전하게 작성한 액션의 URI를 안전하게 소유 한 클라이언트는 안전하지 않은 요청을 대상 URI가 아닌 작업 URI로 푸시합니다 . 조치를 해결하고 "실제"자원을 업데이트하는 것은 API의 작업이며 신뢰할 수없는 네트워크와 분리됩니다.

서버는 비즈니스를 수행하고 응답을 리턴 하고 동의 된 조치 URI에 대해 응답 을 저장합니다 . 어떤 일이 잘못되면 클라이언트는 요청을 반복합니다 (자연스러운 행동!). 서버가 이미 그것을 본 경우 저장된 응답을 반복하고 다른 작업은 수행하지 않습니다 .

약속을 통해 유사점을 신속하게 발견 할 수 있습니다. 결과를 얻기 전에 자리 표시자를 만들고 반환합니다. 또한 약속과 마찬가지로 한 번에 성공 또는 실패 할 수 있지만 결과를 반복해서 가져올 수 있습니다.

무엇보다 우리는 송수신 응용 프로그램에 고유하게 식별 된 작업을 각각의 환경에서 고유성과 연결할 수있는 기회를 제공합니다. 그리고 우리는 고객으로부터 책임있는 행동을 요구하고 시행 할 수 있습니다 : 원하는만큼 요청을 반복하십시오. 그러나 기존 행동에서 결정적인 결과를 얻을 때까지 새로운 행동을 취하지 마십시오.

이와 같이 수많은 난제가 사라집니다. 반복되는 삽입 요청은 중복을 생성하지 않으며 우리가 데이터를 소유 할 때까지 실제 자원을 생성하지 않습니다. (데이터베이스 열은 null이 허용되지 않을 수 있습니다). 반복되는 업데이트 요청은 호환되지 않는 상태에 도달하지 않으며 후속 변경 사항을 덮어 쓰지 않습니다. 클라이언트는 어떤 이유로 든 (클라이언트가 충돌하거나 응답이 누락 된 경우 등) 원본 확인을 가져올 수 있습니다.

연속 삭제 요청은 404 오류가 발생하지 않고 원래 확인을보고 처리 할 수 ​​있습니다. 일이 예상보다 오래 걸리는 경우 잠정적으로 대응할 수 있으며 고객이 최종 결과를 확인할 수있는 장소가 있습니다. 이 패턴의 가장 좋은 부분은 Kung-Fu (Panda) 속성입니다. 우리는 약점을 보았습니다. 클라이언트가 응답을 이해하지 못하면 언제든지 요청을 반복 하여 강점을 나타낼 수 있습니다.

이것이 RESTful이 아니라는 것을 알려주기 전에 REST 원칙을 존중하는 여러 가지 방법을 고려해보십시오. 클라이언트는 URL을 구성하지 않습니다. API는 의미 체계가 약간 변경되었지만 검색 가능 상태로 유지됩니다. HTTP 동사가 적절하게 사용됩니다. 이것이 구현하기위한 거대한 변화라고 생각한다면, 나는 그것이 경험이 아니라고 말할 수 있습니다.

엄청난 양의 데이터를 저장할 생각이라면 볼륨을 말하자. 일반적인 업데이트 확인은 킬로바이트 분량입니다. HTTP는 현재 1 ~ 2 분을 명확하게 응답합니다. 1 주일 동안 행동을 저장하더라도 고객은 따라 잡을 기회가 충분합니다. 볼륨이 매우 큰 경우 전용 산 관련 키 값 저장소 또는 메모리 내 솔루션이 필요할 수 있습니다.


이미 말한 것을 다시 말하면서, PUT 은 클라이언트 가 리소스를 생성 할 때 URL 이 끝날 것을 제어한다는 것을 기억해야 합니다. PUTPOST 사이의 선택의 일부는 클라이언트가 URL 스키마가 무엇이든 일치 하는 올바른 정규화 된 URL 을 제공하는 것을 얼마나 신뢰할 수 있는지에 관한 것 입니다.

클라이언트가 올바르게 작동하는지 완전히 신뢰할 수없는 경우 POST 를 사용하여 새 항목을 만든 다음 URL을 응답으로 클라이언트에 다시 보내는 것이 더 적절합니다 .





put