API REST no Jitterbit App Builder

Visão geral

REST é um estilo de arquitetura de serviço web. REST define um conjunto de operações sem estado que podem ser executadas em recursos. O App Builder permite que 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 aplicativo. Embora os aplicativos normalmente descrevam uma interface de usuário, eles possuem diversas propriedades que também se aplicam a serviços web:

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

O App Builder estende o conceito de aplicativo para incluir serviços web. Especificamente, os desenvolvedores podem definir um endpoint para um aplicativo. Por exemplo, o endpoint do aplicativo Sales pode ser sales. O URI correspondente pode ter a seguinte 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". Os 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 próprio serviço, o desenvolvedor determina o endpoint do objeto de dados. Por exemplo, o objeto de dados Clientes pode ter um endpoint de clientes. 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 assim:

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 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.

A API REST do App Builder atualmente 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 oferece suporte a 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. Atualmente, isso é suportado por meio de um POST. Normalmente, o PATCH usa um formato específico para cada patch, o que complica 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".
Mudança - Interações com a IU invocam um pseudoevento que executa padrões e validações sem persistir as alterações. Os consumidores não podem simular o evento de Mudança.
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 não têm estado.
Os Endpoints são modelados como recursos.
As 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 são inseguras, mas 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.
As operações POST não são seguras nem idempotentes. Por isso, podem conter dados parciais.
Os códigos de status HTTP indicam se ocorreu um erro.
Tipos de mídia são usados para realizar a negociação de conteúdo. No momento, porém, 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 dos 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 aos 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 oferece suporte aos seguintes recursos:

Paginação via $offset e $limit parâmetros. O limite padrão é 10; o limite máximo é 100.
Ordenação por meio de um $sort parâmetro. O $sort O parâmetro pode receber uma lista de nomes de campos delimitada por vírgulas. Prefixe o nome do campo com um hífen (-) 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). Especifique 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 O 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 substring serão retornadas (por exemplo, $q=miami). Observe 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 na 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 informativa como parte da resposta. Cada validação incluirá um validationId, uma mensagem (definida no IDE) e a gravidade 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-Vinyl-Ignore-Warnings em uma nova solicitação ao 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-Vinyl-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.
Somente a filtragem por comparações simples de igualdade é suportada.