Maneira RESTful de criar vários itens em uma solicitação

Estou trabalhando em um pequeno programa de servidor cliente para coletar pedidos. Eu quero fazer isso de uma "maneira REST (completa)".

O que eu quero fazer é:

Colete todas as linhas de pedido (produto e quantidade) e envie o pedido completo ao servidor

No momento, vejo duas opções para fazer isso:

1. Envie cada linha de pedido para o servidor: POST qty e product_id

Na verdade, não quero fazer isso porque desejo limitar o número de solicitações ao servidor, portanto, a opção 2:

2. Colete todas as linhas de pedidos e envie-as para o servidor de uma só vez.

Como devo implementar a opção 2? algumas idéias que tenho são: Quebra todas as linhas de pedido em um objeto JSON e enviá-lo ao servidor ou use uma matriz para postar as linhas de pedido.

É uma boa ideia ou boa prática implementar a opção 2 e, em caso afirmativo, como devo fazê-lo.

O que é uma boa prática?

Acredito que outra maneira correta de abordar isso seria criar outro recurso que represente sua coleção de recursos. Por exemplo, imagine que temos um ponto de extremidade /api/sheep/{id}e podemos POST /api/sheeppara criar um recurso de ovelha.

Agora, se queremos oferecer suporte à criação em massa, devemos considerar um novo recurso de rebanho em /api/flock(ou /api/<your-resource>-collectionse você não tiver um nome com um significado melhor). Lembre-se de que os recursos não precisam ser mapeados para o seu banco de dados ou modelos de aplicativos . Este é um equívoco comum.

Os recursos são uma representação de nível superior, não relacionada aos seus dados. Operar em um recurso pode ter efeitos colaterais significativos, como disparar um alerta para um usuário, atualizar outros dados relacionados, iniciar um processo de longa duração etc. Por exemplo, podemos mapear um sistema de arquivos ou mesmo o unixps comando como uma API REST.

Eu acho que é seguro assumir que operar um recurso também pode significar criar várias outras entidades como efeito colateral.

Embora as operações em massa (por exemplo, criação de lote) sejam essenciais em muitos sistemas, elas não são formalmente tratadas pelo estilo de arquitetura RESTful.

Descobri que o POST de uma coleção, como você sugeriu, basicamente funciona, mas surgem problemas quando você precisa relatar falhas em resposta a essa solicitação. Esses problemas são piores quando várias falhas ocorrem por causas diferentes ou quando o servidor não suporta transações. Minha sugestão é que, se não houver problemas de desempenho, por exemplo, quando o provedor de serviços estiver na LAN (não na WAN) ou os dados forem relativamente pequenos, vale a pena enviar 100 solicitações POST para o servidor. Mantenha as coisas simples, comece com solicitações separadas e se você tiver um problema de desempenho, tente otimizar.

O Facebook explica como fazer isso: https://developers.facebook.com/docs/graph-api/making-multiple-requests

Solicitações em lote simples

A API em lote recebe uma matriz de solicitações HTTP lógicas representadas como matrizes JSON - cada solicitação possui um método (correspondente ao método HTTP GET / PUT / POST / DELETE etc.), um URL_relativo (a parte da URL após graph.facebook. com), matriz de cabeçalhos opcionais (correspondente aos cabeçalhos HTTP) e um corpo opcional (para solicitações POST e PUT). A API do Lote retorna uma matriz de respostas HTTP lógicas representadas como matrizes JSON - cada resposta possui um código de status, uma matriz de cabeçalhos opcional e um corpo opcional (que é uma sequência codificada em JSON).

Sua ideia parece válida para mim. A implementação é uma questão de sua preferência. Você pode usar JSON ou apenas parâmetros para isso (matriz "order_lines []") e fazer

POST /orders

Como você criará mais recursos ao mesmo tempo em uma única ação (ordem e suas linhas), é vital validar todos e cada um deles e salvá-los somente se todos forem aprovados na validação, ou seja. você deve fazer isso em uma transação.

Eu acho que é melhor enviar solicitações separadas dentro de uma única conexão . Obviamente, seu servidor da web deve suportá-lo

Ultimamente, tenho lutado com isso e aqui está o que estou trabalhando.

Se um POST que adicionar vários recursos for bem-sucedido, retorne 200 OK (eu estava considerando um 201, mas o usuário finalmente não pousa em um recurso que foi criado) junto com uma página que exibe todos os recursos adicionados, seja em leitura -só moda ou editável. Por exemplo, um usuário pode selecionar e POSTAR várias imagens para uma galeria usando um formulário que compreende apenas uma entrada de arquivo único. Se a solicitação POST for bem-sucedida, o usuário receberá um conjunto de formulários para cada representação de recurso de imagem criada, permitindo que você especifique mais detalhes sobre cada uma (nome, descrição, etc.).

Caso um ou mais recursos não sejam criados, o manipulador POST interrompe todo o processamento e anexa cada mensagem de erro individual a uma matriz. Em seguida, um 419 Conflict é retornado e o usuário é roteado para uma página de erro 419 Conflict que apresenta o conteúdo da matriz de erros, bem como um caminho de volta ao formulário enviado.

Você não deseja enviar os cabeçalhos HTTP para 100 linhas de pedido. Você não deseja gerar mais solicitações além do necessário.

Envie o pedido inteiro em um objeto JSON para o servidor, para: servidor / pedido ou servidor / pedido / novo. Retorne algo que aponte para: server / order / order_id

Considere também usar CREATE PUT em vez de POST