REST: 한 번의 요청으로 여러 리소스 업데이트 - 표준입니까, 아니면 피해야 합니까?

REST: 한 번의 요청으로 여러 리소스 업데이트 - 표준입니까, 아니면 피해야 합니까?

심플한 REST API:

• GET: items/{id} - 지정된 ID로 항목에 대한 설명을 반환합니다.
• PUT: items/{id} - 지정된 ID로 항목을 업데이트 또는 만듭니다.
• DELETE: items/{id} - 지정된 ID의 항목을 삭제합니다.

다음으로 해당 API 확장을 나타냅니다.

• GET: 아이템?filter - 필터와 일치하는 모든 항목 ID를 반환합니다.
• PUT: items - JSON payload에 설명된 항목 세트를 업데이트 또는 만듭니다.
• [DELETE: items - JSON payload로 기술된 항목 목록을 삭제합니다]<-Not Correct

PUT/DELETE items/{id}에서 쉽게 접근할 수 있는 DELETE 및 PUT 작업 재활용 기능에 관심이 있습니다.

질문:.이런 API를 제공하는 것이 일반적인가요?

다른 방법:싱글 커넥션의 복수 요구를 발행하는 시대에는 변경이 성공하거나 실패하기 때문에 비용이 적게 들고 더 원자적으로 동작하지만 NOSQL 데이터베이스의 시대에는 내부 서버에서 요청 처리가 중단되거나 어떤 이유로 인해 중단되더라도 목록의 변경이 이미 이루어졌을 수 있습니다.

[업데이트]

백악관 웹 표준과 Wikipedia: REST 예제를 검토한 후 다음 API 예제를 작성했습니다.

심플한 REST API:

• GET: items/{id} - 지정된 ID로 항목에 대한 설명을 반환합니다.
• PUT: items/{id} - 지정된 ID로 항목을 업데이트 또는 만듭니다.
• DELETE: items/{id} - 지정된 ID의 항목을 삭제합니다.

상위 리소스 API:

• GET: 아이템?filter - 필터와 일치하는 모든 항목 ID를 반환합니다.
• POST: items - JSON payload에서 설명하는 항목 세트를 업데이트 또는 만듭니다.

/items의 PUT 및 DELETE는 지원되지 않으며 금지되어 있습니다.

POST를 사용하면 교환이 아니라 추가하는 동안 동봉된 리소스에 새로운 아이템을 작성할 수 있습니다.

HTTP 시멘틱스 POST 읽기:

추가 작업을 통해 데이터베이스 확장

여기서 PUT 메서드는 HTTP Symantics PUT에서 인용된 것과 동등한 표현을 반환하기 위해 전체 컬렉션을 교체해야 합니다.

특정 표현의 PUT에 성공하면 동일한 타깃리소스로 후속 GET이 200(OK) 응답으로 동등한 표현이 반환되는 것을 나타냅니다.

[UPDATE2]

여러 개체의 업데이트 측면에서 보다 일관된 것으로 보이는 다른 방법은 패치 방식인 것 같습니다.PUT 와 PATC 의 차이는, Draft RFC 5789 에 다음과 같이 기술되어 있습니다.

PUT 요구와 PATCH 요구의 차이는 서버가 폐쇄된 엔티티를 처리하여 Request-URI에 의해 식별된 리소스를 변경하는 방식에 반영됩니다.PUT 요청에서 동봉된 엔티티는 원본 서버에 저장된 리소스의 수정된 버전으로 간주되며 클라이언트는 저장된 버전의 교체를 요구합니다.단, PATCH를 사용하는 경우 동봉된 엔티티에는 현재 오리진서버에 있는 자원을 새로운 버전을 작성하기 위해 변경하는 방법이 기재되어 있습니다.PATCH 메서드는 Request-URI에 의해 식별된 리소스에 영향을 줍니다.또, 다른 자원에도 악영향을 미칠 가능성이 있습니다.즉, 패치 적용에 의해 새로운 리소스가 작성되거나 기존 리소스가 변경될 수 있습니다.

따라서 POST에 비해 PATCH는 UPDATE를 허용하기 때문에 PATCH는 수정하지 않고 의미 있는 추가만 허용하기 때문에 PATCH를 사용하는 것이 좋습니다.

따라서 POST가 잘못된 것 같습니다.또한 제안된 API를 다음과 같이 변경해야 합니다.

심플한 REST API:

• GET: items/{id} - 지정된 ID로 항목에 대한 설명을 반환합니다.
• PUT: items/{id} - 지정된 ID로 항목을 업데이트 또는 만듭니다.
• DELETE: items/{id} - 지정된 ID의 항목을 삭제합니다.

상위 리소스 API:

• GET: 아이템?filter - 필터와 일치하는 모든 항목 ID를 반환합니다.
• POST: items - JSON payload에서 설명한 대로 하나 이상의 항목을 만듭니다.
• 패치: 항목 - JSON payload 설명에 따라 하나 이상의 항목을 작성 또는 업데이트합니다.

예를 들어, 컬렉션에 패치를 적용할 수 있습니다.

PATCH /items
[ { id: 1, name: 'foo' }, { id: 2, name: 'bar' } ]

내의 URL)를합니다./items/1그리고 요청 기관에는 없지만, 이것은 좋은 실용적인 해결책인 것 같습니다.

단일 호출로 삭제, 생성 및 업데이트를 지원하기 위해 표준 REST 규칙에서는 실제로 지원되지 않습니다.한 가지 방법은 콜을 조합할 수 있는 특별한 "배치" 서비스입니다.

POST /batch
[
  { method: 'POST', path: '/items', body: { title: 'foo' } },
  { method: 'DELETE', path: '/items/bar' }
]

그러면 내장된 각 요구에 대한 상태 코드가 포함된 응답이 반환됩니다.

[ 200, 403 ]

표준적이진 않지만, 해봤는데 효과가 있어요.

한 번의 요청으로 여러 리소스 업데이트 - 표준입니까, 아니면 피해야 합니까?

단순한 REST API의 일반적인 스킴에 맞지 않는 원자 배치 조작이나 기타 자원 관련 조작을 실행할 필요가 있는 경우도 있습니다만, 필요한 경우는 피할 수 없습니다.

표준입니까?

REST API 규격은 보편적으로 인정되고 있지 않기 때문에 이 질문은 답변하기 어렵습니다.그러나 jsonapi.org, restfulapi.net, Microsoft api 설계 가이드 또는 IBM REST API Conventions 등 일반적으로 인용되는 API 설계 가이드라인을 보면 이러한 작업이 REST API의 표준 기능으로 이해되지 않는다는 것을 알 수 있습니다.

단, 콜론을 사용하여 리소스를 통해 연결할 수 있는 "커스텀" 메서드의 생성을 언급하는 Google API 디자인 가이드는 예외입니다.https://service.name/v1/some/resource/name:customVerb 배치 하고 있습니다.「 「 」 「 」 「 」 「 」 。

사용자 지정 메서드는 리소스, 컬렉션 또는 서비스와 연결할 수 있습니다.임의 요청을 받고 임의 응답을 반환할 수 있으며 스트리밍 요청 및 응답도 지원합니다. [...] 사용자 정의 메서드는 가장 유연한 의미론을 가지므로 HTTP POST 동사를 사용해야 합니다. 성능에 중요한 메서드의 경우 요청별 오버헤드를 줄이기 위해 사용자 정의 배치 방법을 제공하는 것이 유용할 수 있습니다.

이 예에서는 Google API 가이드에 따라 다음 작업을 수행합니다.

POST /api/items:batchUpdate

일부 API는 했습니다./batch예를 들어 Google의 gmail API와 같은 엔드포인트입니다.

또한 restfulapi.net에서 설명한 바와 같이 PUT을 통해 항목의 전체 목록을 한 번에 저장하고 가져오는 리소스 "스토어"의 개념도 있습니다. 단, 이 개념은 서버 관리 리소스 수집에는 포함되지 않습니다.

저장소는 클라이언트 관리 리소스 저장소입니다.저장소 리소스는 API 클라이언트가 리소스를 넣고 다시 꺼내 삭제 시기를 결정할 수 있도록 합니다.스토어는 새로운 URI를 생성하지 않습니다.대신 저장된 각 리소스에는 클라이언트가 처음 저장소에 저장했을 때 선택한 URI가 있습니다.

---

원래의 질문에 답한 후, 아직 언급되지 않은 문제에 대한 또 다른 접근방식을 소개합니다.이 접근법은 조금 파격적이며 일반적인 REST API 엔드포인트 명명 방식만큼 예쁘지 않습니다.저는 개인적으로 이 접근방식을 따르지 않지만 그래도 생각해봐야 한다고 생각했습니다.

즉, 엔드포인트 경로 명명 방식을 통해 리소스에 대한 CRUD 작업과 다른 리소스 관련 작업(배치 작업 등)을 구분할 수 있습니다.

예를 들어, "회사" 리소스에 대해 CRUD 작업을 수행할 수 있는 RESTful API와 같은 리소스 지향 CRUD 체계에 맞지 않는 일부 "회사" 관련 작업을 수행할 수 있는 RESTful API를 생각해 보십시오.

이제 리소스를 바로 아래에 노출하는 대신/api/companies(예:/api/companies/22)는 다음 항목을 구분할 수 있습니다.

• /api/companies/items– 기업 리소스 수집
• /api/companies/ops– 즉, 회사 자원에 관한 업무

위해서items일반적인 RESTful api http-methods 와 resource-url naming-scemes 가 적용됩니다(예를 들어 여기서 또는 여기서 설명됨).

POST    /api/companies/items
GET     /api/companies/items
GET     /api/companies/items/{id}
DELETE  /api/companies/items/{id}
PUT     /api/companies/items/{id}

회사 관련 업무의 경우/api/companies/ops/POST를 통한 루트 프리픽스 및 콜 조작.

POST    /api/companies/ops/batch-update
POST    /api/companies/ops/batch-delete
POST    /api/companies/ops/garbage-collect-old-companies
POST    /api/companies/ops/increase-some-timestamps-just-for-fun
POST    /api/companies/ops/perform-some-other-action-on-companies-collection

POST 요구로 리소스가 생성될 필요는 없기 때문에 POST는 여기서 사용하는 적절한 방법입니다.

POST 메서드로 수행된 작업으로 인해 리소스가 URI로 식별되지 않을 수 있습니다.https://www.rfc-editor.org/rfc/rfc2616#section-9.5

REST의 개념을 이해하는 한, 하나의 요청으로 여러 자원의 업데이트를 커버합니다.여기서 중요한 것은 이러한 여러 리소스 주위에 컨테이너가 있다고 가정하고 이를 하나의 리소스로 간주하는 것입니다.예를 들어, ID 목록이 다른 여러 리소스를 포함하는 리소스를 식별한다고 가정할 수 있습니다.

Wikipedia의 이러한 예에서는 자원에 대해서도 복수형으로 설명합니다.

언급URL : https://stackoverflow.com/questions/32098423/rest-updating-multiple-resources-with-one-request-is-it-standard-or-to-be-avo