API REST no Jitterbit App Builder

Visão geral

REST é um estilo arquitetônico de serviço web. REST define um conjunto de operações sem estado que podem ser executadas em recursos. O App Builder permite que os desenvolvedores publiquem objetos de dados como recursos REST. Os consumidores podem executar operações nesses recursos que se traduzem em invocações de eventos de objetos de dados.

Aplicações como serviços web

O ambiente de design do App Builder é organizado em torno do conceito de um aplicativo. Embora os aplicativos normalmente descrevam uma interface de usuário, os aplicativos têm várias propriedades que também são aplicáveis a serviços da web:

Os aplicativos fornecem acesso a diversas fontes de dados.
Grupos recebem privilégios para um aplicativo.

O App Builder estende o conceito de um aplicativo para incluir serviços da web. Especificamente, os desenvolvedores têm a capacidade de definir um endpoint para um aplicativo. Por exemplo, o endpoint para o aplicativo Sales pode ser sales. O URI correspondente pode ter esta aparência:

https://example.com/App Builder/rest/v1/sales

Objetos de dados como recursos

O princípio organizador do REST é o conceito de "recurso". Recursos podem representar uma coleção de itens ou um único item. Em termos do App Builder, um objeto de dados é representado como uma coleção com linhas individuais representadas como itens nessa coleção.

Assim como o serviço em si, o desenvolvedor determina o endpoint do objeto de dados. Por exemplo, o objeto de dados Customers pode ter um endpoint de customers. Nesse caso, o URI correspondente pode ter a seguinte aparência:

https://example.com/App Builder/rest/v1/sales/customers

O URI para um item específico (linha) pode ser parecido com este:

https://example.com/App Builder/rest/v1/sales/customers/b603b276-a9bf-4328-88ff-8994176c38d1

A chave primária aparece no caminho do URI.

Chaves primárias compostas podem ser especificadas separando as chaves com uma vírgula:

https://example.com/App Builder/rest/v1/sales/customers/abc,def

Eventos como métodos HTTP

REST define um conjunto de operações correspondentes aos métodos HTTP. A API REST do App Builder suporta os seguintes métodos HTTP:

GET /collection - Recupera os itens dentro de uma coleção. Isso mapeia para o evento Filter.
POST /collection - Adiciona um item à coleção. Isso mapeia para o evento Insert.
GET /collection/item - Recupera um único item da coleção. Isso mapeia para o evento Filter.
POST /collection/item - Atualiza um item na coleção. Isso mapeia para o evento Update.
DELETE /collection/item - Exclui um item da coleção. Isso mapeia para o evento DELETE.

Atualmente, a API REST do App Builder não oferece suporte aos seguintes métodos HTTP:

HEAD - O método HEAD permite que os consumidores recuperem os cabeçalhos de resposta HTTP. No momento, o App Builder não suporta essa operação.
OPÇÕES - O método OPÇÕES permite que os consumidores determinem quais métodos são suportados.
PUT (coleção ou item) - O método PUT permite que os consumidores criem um item (ao endereçar a coleção) ou atualizem um item (ao endereçar o item). No entanto, como PUT é idempotente, ele deve incluir todos os campos. Isso limita sua utilidade em muitos cenários.
PATCH - O método PATCH permite que os consumidores atualizem parte de um item. Isso é atualmente suportado por meio de um POST. Normalmente, o PATCH usa um formato específico de patch, complicando a implementação.

Nem todos os eventos do App Builder podem ser publicados:

Novo - O evento New do App Builder cria uma linha não persistente, aplicando quaisquer padrões. Os consumidores não podem invocar o evento New.
Change - Interações com a UI invocam um pseudo-evento que executa padrões e validações sem persistir mudanças. Os consumidores não podem simular o evento Change.
Eventos definidos pelo usuário - Além dos eventos intrínsecos, os desenvolvedores podem definir seus próprios eventos. Atualmente, eles não podem ser mapeados para métodos de recursos.

Princípios de design RESTful

Na medida do possível, a API REST do App Builder segue estes princípios RESTful:

Os serviços são independentes de estado.
Os Endpoints são modelados como recursos.
Operações GET são seguras. Uma operação "segura" é aquela que não tem efeitos colaterais. Por exemplo, recuperar uma lista de clientes não altera a lista de clientes.
Operações DELETE não são seguras, mas são idempotentes. No entanto, enquanto a primeira solicitação (bem-sucedida) para excluir um item retornará um código de status 200, a segunda solicitação retornará um 404.
Operações POST não são seguras nem idempotentes. Por isso, operações POST podem conter dados parciais.
Os códigos de status HTTP indicam se ocorreu um erro.
Tipos de mídia são usados para executar negociação de conteúdo. No momento, no entanto, o App Builder suporta apenas JSON (application/json) e UTF-8.

O App Builder não adere a todos os princípios RESTful:

As respostas de recursos são encapsuladas em um envelope. Isso permite que o App Builder inclua informações adicionais, como mensagens de eventos e resultados de validação.
As respostas de recursos não são hipermídia: elas não incluem links para outros recursos.

Convenções REST URI

No nível de coleção, o método GET suporta os seguintes recursos:

Paginação via $offset e $limit parâmetros. O limite padrão é 10; o limite máximo é 100.
Classificando por meio de um $sort parâmetro. O $sort parâmetro pode receber uma lista delimitada por vírgulas de nomes de campos. Prefixe o nome do campo com um traço (-) para classificar o campo em ordem decrescente. Por exemplo, a especificação de classificação $sort=-country,companyName classificaria a coleção por país, em ordem decrescente, e companyName, em ordem crescente.
Seleção via $fields parâmetro. O $fields O parâmetro pode receber uma lista de nomes de campos delimitada por vírgulas (por exemplo $fields=customerId,country). Especifica o asterisco (*) para recuperar todos os campos de recursos (por exemplo $fields=*).
Pesquisa por palavra-chave através de um $q parâmetro. O $q parâmetro recebe uma string e tenta corresponder aos valores da coluna. Quaisquer linhas da tabela que tenham pelo menos um valor de coluna que contenha o parâmetro $q como uma substring serão retornadas (por exemplo, $q=miami). Note que a correspondência não diferencia maiúsculas de minúsculas.
Filtragem por meio de comparações simples de igualdade. Para limitar os resultados, especifique o nome e o valor do campo (por exemplo, countryId=USA).
Contagem através do $count parâmetro. Por padrão, o App Builder não retornará uma contagem total do número de itens dentro da coleção. Para incluir a contagem, anexe o parâmetro count (por exemplo $count=true).

Convenções para parâmetros:

Parâmetros que se referem a campos de recursos não são prefixados.
Parâmetros que operam na própria coleção são prefixados com um cifrão ($).

Validação

Um evento pode retornar um ou mais erros, avisos ou resultados de validação informacional como parte da resposta. Cada validação incluirá um validationId, uma mensagem (definida no IDE) e a severidade da validação ("erro", "aviso", "informação").

Se você quiser ignorar um aviso, inclua os validationIds fornecidos como o valor de um cabeçalho X- App Builder -Ignore-Warnings em uma nova solicitação para o endpoint.

Por exemplo, para a seguinte resposta:

{
  "item": {
    "contactId": "8d20b593-aa41-4bbb-8bee-58f17ac2bf32",
    "name": "Company Name"
  },
  "message": null,
  "validations": [
    {
      "validationId": "8d20b593-aa41-4bbb-8bee-58f17ac2bf32",
      "message": "32 emails will be sent, are you sure?",
      "severity": "warning"
    },
    {
      "validationId": "6bad40b7-2504-4243-9e90-100bcc7bfd13",
      "message": "No subject was provided, use default?",
      "severity": "warning"
    }
  ],
  "status": 400
}

Uma nova solicitação (para o mesmo endpoint e os mesmos dados) precisaria incluir as seguintes informações de cabeçalho:

X-App Builder-Ignore-Warnings: "8d20b593-aa41-4bbb-8bee-58f17ac2bf32", "6bad40b7-2504-4243-9e90-100bcc7bfd13"

Problemas e limitações conhecidos

Campos binários como arquivos não são suportados atualmente.
O único tipo de conteúdo suportado é JSON (application/json).
A única codificação de texto suportada é UTF-8.
As coleções são limitadas a retornar 100 itens por vez.
Chaves primárias compostas não podem conter vírgulas.
Apenas filtragem por comparações de igualdade simples é suportada.