하나의 요청으로 여러 항목을 만드는 RESTful 방법

주문을 수집하기 위해 소규모 클라이언트 서버 프로그램을 개발 중입니다. 나는 이것을 "REST (ful) 방식"으로하고 싶다.

내가하고 싶은 것은 :

모든 주문 라인 (제품 및 수량)을 수집하고 전체 주문을 서버로 보냅니다.

현재이 작업을 수행 할 수있는 두 가지 옵션이 있습니다.

1. 각 주문 라인을 서버로 전송 : POST qty 및 product_id

옵션 2이므로 서버에 대한 요청 수를 제한하고 싶기 때문에 실제로이 작업을 수행하고 싶지 않습니다.

2. 모든 주문 라인을 수집하여 한 번에 서버로 보냅니다.

옵션 2를 어떻게 구현해야합니까? 내가 가진 몇 가지 아이디어는 : 모든 주문 라인을 JSON 객체로 래핑하고 이것을 서버로 보내거나 배열을 사용하여 주문 라인을 게시하는 것입니다.

옵션 2를 구현하는 것이 좋은 생각입니까 아니면 좋은 습관입니까? 그렇다면 어떻게해야합니까?

좋은 습관이란 무엇입니까?

이에 접근하는 또 다른 올바른 방법은 리소스 컬렉션을 나타내는 또 다른 리소스를 만드는 것입니다. 예를 들어, 다음과 같은 엔드 포인트 /api/sheep/{id}가 있고 /api/sheep양 리소스를 생성 하기 위해 POST를 수행 할 수 있다고 가정합니다.

이제 대량 생성을 지원하려면에서 새 무리 리소스를 고려해야합니다 /api/flock(또는 /api/<your-resource>-collection더 의미있는 이름이없는 경우). 기억 자원 데이터베이스 또는 앱 모델에 매핑 할 필요가 없습니다 . 이것은 일반적인 오해입니다.

리소스는 데이터와 관련이없는 상위 수준의 표현입니다. 리소스에 대한 작업은 사용자에게 경고를 보내거나, 다른 관련 데이터를 업데이트하고, 수명이 긴 프로세스를 시작하는 등의 심각한 부작용이있을 수 있습니다. 예를 들어 파일 시스템이나 Unix ps명령을 REST API로 매핑 할 수 있습니다 .

자원을 운영하는 것이 부작용으로 다른 여러 엔티티를 생성하는 것을 의미 할 수도 있다고 가정하는 것이 안전하다고 생각합니다.

대량 작업 (예 : 일괄 생성)은 많은 시스템에서 필수적이지만 RESTful 아키텍처 스타일에 의해 공식적으로 해결되지는 않습니다.

제안한대로 컬렉션을 게시하는 것은 기본적으로 작동하지만 이러한 요청에 대한 응답으로 실패를보고해야하는 경우 문제가 발생합니다. 이러한 문제는 다른 원인으로 인해 여러 번 실패하거나 서버가 트랜잭션을 지원하지 않을 때 더욱 악화됩니다. 예를 들어 서비스 공급자가 LAN (WAN 아님)에 있거나 데이터가 비교적 작은 경우 성능 문제가없는 경우 서버에 100 개의 POST 요청을 보내는 것이 좋습니다. 단순하게 유지하고 별도의 요청으로 시작하고 성능 문제가있는 경우 최적화를 시도하십시오.

Facebook은이를 수행하는 방법을 설명합니다. https://developers.facebook.com/docs/graph-api/making-multiple-requests

간단한 일괄 요청

배치 API는 JSON 배열로 표시된 논리적 HTTP 요청의 배열을받습니다. 각 요청에는 메서드 (HTTP 메서드 GET / PUT / POST / DELETE 등에 해당), relative_url (graph.facebook. com), 선택적 헤더 배열 (HTTP 헤더에 해당) 및 선택적 본문 (POST 및 PUT 요청 용). Batch API는 JSON 배열로 표시된 논리적 HTTP 응답 배열을 반환합니다. 각 응답에는 상태 코드, 선택적 헤더 배열 및 선택적 본문 (JSON 인코딩 문자열)이 있습니다.

당신의 아이디어는 나에게 타당 해 보입니다. 구현은 선호도의 문제입니다. JSON 또는 매개 변수 만 사용할 수 있습니다 ( "order_lines []"배열).

POST /orders

단일 작업 (주문 및 해당 라인)에서 한 번에 더 많은 리소스를 생성 할 것이기 때문에 각각의 리소스를 확인하고 모두 유효성 검사를 통과 한 경우에만 저장하는 것이 중요합니다. 거래에서해야합니다.

단일 연결 내에서 별도의 요청을 보내는 것이 더 낫다고 생각합니다 . 물론 웹 서버가이를 지원해야합니다.

나는 실제로 최근에 이것과 씨름하고 있으며 여기에 내가 노력하고 있습니다.

여러 리소스를 추가하는 POST가 성공하면 읽기로 추가 된 모든 리소스를 표시하는 페이지와 함께 200 OK (201을 고려했지만 사용자가 궁극적으로 생성 된 리소스에 도달하지 않음)를 반환합니다. -전용 또는 편집 가능한 패션. 예를 들어, 사용자는 단일 파일 입력으로 만 구성된 양식을 사용하여 여러 이미지를 선택하고 갤러리에 게시 할 수 있습니다. POST 요청이 전체적으로 성공하면 사용자에게 생성 된 각 이미지 리소스 표현에 대한 양식 집합이 제공되어 각각에 대한 세부 정보 (이름, 설명 등)를 지정할 수 있습니다.

하나 이상의 리소스 생성에 실패한 경우 POST 처리기는 모든 처리를 중단하고 각 개별 오류 메시지를 어레이에 추가합니다. 그런 다음 419 Conflict가 반환되고 사용자는 오류 배열의 내용과 제출 된 양식으로 돌아가는 방법을 제공하는 419 Conflict 오류 페이지로 라우팅됩니다.

100 개의 주문 라인에 대한 HTTP 헤더를 보내지 않을 것입니다. 필요한 것보다 더 많은 요청을 생성하고 싶지 않습니다.

하나의 JSON 객체에있는 전체 주문을 server / order 또는 server / order / new로 서버에 보냅니다. 가리키는 것을 반환 : server / order / order_id

POST 대신 CREATE PUT 사용을 고려하십시오.