Noções básicas sobre API

A meta para a API do Adobe Workfront é simplificar a criação de integrações com o Workfront introduzindo uma arquitetura RESTful que opera via HTTP. Este documento supõe que você esteja familiarizado com as respostas REST e JSON e descreve a abordagem adotada pela API do Workfront.

Uma familiaridade com o esquema do Workfront ajudará a entender as relações de banco de dados que podem ser usadas para obter dados do Workfront para fins de integração.

Limites e diretrizes

Para garantir um desempenho consistente do sistema sob demanda do Workfront, a API do Workfront limita os threads de API simultâneos. Essa medida de proteção evita problemas do sistema causados por chamadas de API abusivas. O ambiente Sandbox tem o mesmo limite de thread de API simultâneo em vigor, permitindo que clientes e parceiros testem com precisão as chamadas de API antes de liberar o código para produção.

Para ambientes de produção, pré-visualização e test drive, as solicitações de usuários finais têm um tamanho máximo de URI de 8892 bytes, pois estão sendo roteadas por meio da CDN do Workfront (Akamai). Esse limite se aplica somente aos URIs roteados por meio da CDN.

Isenção de responsabilidade

Qualquer uso da API deve ser testado no ambiente beta do Workfront antes de ser executado no ambiente de produção. Se um cliente usar a API para um processo que o Workfront considere razoavelmente oneroso para o software sob demanda (ou seja, que o processo causa um efeito negativo materialmente no desempenho do software para outros clientes), o Workfront reserva-se o direito de solicitar que o cliente descontinue esse processo. Se o cliente não cumprir e o problema persistir, o Workfront reserva-se o direito de encerrar o processo.

URL da API do Workfront

Para obter informações sobre o URL que você usará para chamar a API do Workfront, consulte Formato de domínio para chamadas de API do Adobe Workfront.

Noções básicas de REST

Esta seção fornece uma introdução de alto nível sobre como interagir com a API REST do Workfront para os seguintes princípios de REST:

URI do objeto

Cada objeto no sistema recebe um URI exclusivo que consiste no tipo de objeto e na ID. Os exemplos a seguir mostram URIs que descrevem três objetos exclusivos:

/attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0
/attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d1
/attask/api/v15.0/issue/4c78821c0000d6fa8d5e52f07a1d54d2

O tipo de objeto não diferencia maiúsculas de minúsculas e pode ser o ObjCode abreviado (como proj) ou o nome alternativo do objeto (projeto).

Para obter uma lista de objetos, ObjCodes válidos e campos de objeto, consulte API Explorer.

Operações

Os objetos são manipulados enviando uma solicitação HTTP para seu URI exclusivo. A operação a ser executada é especificada pelo método HTTP.

Os métodos HTTP padrão correspondem às seguintes operações:

Para contornar deficiências do cliente ou limites de tamanho do protocolo, o parâmetro do método pode ser usado para substituir o comportamento HTTP. Por exemplo, uma operação GET pode ser implementada publicando o seguinte URI:

GET /attask/api/v15.0/project?id=4c78...54d0&method=get
GET /attask/api/v15.0/project/4c78...54d0?method=get

Resposta

Cada solicitação recebe uma resposta no formato JSON. A resposta tem um atributo de dados se a solicitação foi bem-sucedida ou um atributo de erro se houve um problema. Por exemplo, a solicitação

GET /attask/api/v15.0/proj/4c7c08b20000002de5ca1ebc19edf2d5

retorna uma resposta de JSON semelhante à seguinte:

{
    "data": [
        {
            "percentComplete": 0,
            "status": "CUR",
            "priority": 2,
            "name": "Brand New Project",
            "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
        } 
    ] 
}

Uma segurança especial foi adicionada às solicitações PUT, POST e DELETE. Qualquer solicitação que resulte em gravação ou exclusão do banco de dados só poderá ser executada se sessionID=abc123 estiver incluído no URI. Os exemplos a seguir mostram como uma solicitação DELETE seria procurada:

GET /attask/api/v15.0/project?id=4c78...54d0&method=delete&sessionID=abc123
GET /attask/api/v15.0/project/4c78...54d0?method=delete&sessionID=abc123

Autenticação

A API autentica cada solicitação para garantir que o cliente tenha acesso para visualizar ou modificar um objeto solicitado.

A autenticação é realizada transmitindo uma ID de sessão que pode ser fornecida usando um dos seguintes métodos:

Solicitar autenticação de cabeçalho

O método preferencial de autenticação é transmitir um cabeçalho de solicitação denominado SessionID que contém o token de sessão. Isso tem a vantagem de estar seguro contra ataques de falsificação de solicitação entre sites (CSRF) e não interferir no URI para fins de armazenamento em cache.

Veja a seguir um exemplo de cabeçalho de solicitação:

GET /attask/api/v15.0/project/search
SessionID: abc1234

Autenticação baseada em cookie

A API usa a mesma autenticação baseada em cookies usada pela interface do usuário da Web para o sistema. Em que, se um cliente fizer logon no Workfront usando a interface da Web, todas as chamadas do AJAX feitas no mesmo navegador usarão a mesma autenticação.

Logon

Usando um nome de usuário e uma senha válidos, você pode usar a seguinte solicitação para obter uma ID de sessão:

POST /attask/api/v15.0/login?username=admin&password=user

Isso define um cookie para autenticar solicitações futuras, bem como retornar uma resposta JSON com a sessionID recém-criada, a userID do usuário conectado e outros atributos de sessão.

Geração de uma chave de API

Você pode gerar uma chave de API ao fazer logon no sistema como esse usuário, conforme mostrado no exemplo a seguir:

PUT /attask/api/v15.0/user?action=generateApiKey&username= username&password=password&method=put

Recuperação de uma chave de API gerada anteriormente

Você também pode recuperar uma chave de API gerada anteriormente para um usuário específico executando getApiKey:

PUT /attask/api/v15.0/user?action=getApiKey&username=user@email.com&password=userspassword&method=put

Você pode usar esse resultado para autenticar qualquer chamada de API adicionando "apiKey" como um parâmetro de solicitação com esse valor no lugar de uma sessionID ou nome de usuário e senha. Isso é benéfico de uma perspectiva de segurança.

A solicitação a seguir é um exemplo de recuperação de dados de um projeto que usa a apiKey:

GET /attask/api/v15.0/project/abc123xxxxx?apiKey=123abcxxxxxxxxx

Invalidação de uma chave de API

Se o valor de apiKey tiver sido comprometido, será possível executar "clearApiKey", que invalida a Chave de API atual, como mostrado no exemplo a seguir:

GET /attask/api/v15.0/user?action=clearApiKey&username=user@email.com&password=userspassword&method=put

Após a limpeza, você pode executar getApiKey novamente para gerar uma nova Chave de API.

Sair

Quando uma sessão é concluída, você pode usar a seguinte solicitação para fazer o logoff do usuário, impedindo qualquer acesso adicional com a sessionID.

GET /attask/api/v15.0/logout?sessionID=abc1234

A sessionID a ser desconectada pode ser especificada como cookie, cabeçalho de solicitação ou parâmetro de solicitação.

Para fazer o logoff de um usuário:

Você sempre deve incluir a sessionID fornecida após o logon ao executar solicitações PUT, POST e DELETE.

Comportamento do GET

Use o método GET do HTTP para recuperar um ou vários objetos e executar relatórios.

Recuperação de objetos

Você pode aprimorar uma pesquisa de objetos usando modificadores e filtros.

Recuperando um objeto usando a ID do objeto

Se você souber a ID de um objeto, poderá recuperá-lo acessando seu URI exclusivo. Por exemplo, a solicitação

GET /attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0

retorna uma resposta semelhante à seguinte:

{
    "percentComplete": 0,
    "status": "CUR",
    "priority": 2,
    "name": "Brand New Project",
    "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
}

Você pode recuperar vários objetos na mesma solicitação especificando o parâmetro de solicitação de ID e fornecendo uma lista de IDs separadas por vírgulas, como mostrado no exemplo a seguir:

GET /attask/api/v15.0/project?id=4c78...54d0,4c78...54d1

Observe que a solicitação /attask/api/v15.0/project?id=… é igual à solicitação /attask/api/v15.0/project/....

Recuperando um objeto usando o URI

Se quiser recuperar um objeto por critérios diferentes da ID, procure o URI.

Por exemplo, você pode usar a seguinte solicitação para retornar uma lista de todos os projetos no sistema:

GET /attask/api/v15.0/project/search

Você pode especificar filtros usando os parâmetros da solicitação como pares de nome-valor. Por exemplo, o exemplo a seguir mostra uma solicitação que localizaria todos os projetos atuais:

GET /attask/api/v15.0/project/search?status=CUR

A solicitação a seguir encontra todas as tarefas que ainda não foram concluídas e que foram atribuídas a um usuário chamado John.

GET /attask/api/v15.0/task/search?percentComplete=100
&percentComplete_Mod=lt &assignedTo:firstName=John

Uso de Modificadores de Pesquisa

A tabela a seguir lista alguns dos modificadores que podem ser usados com a API do Workfront.

…status=cls&status_Mod=eq…

…status=cls&status_Mod=ne…

…percentComplete=50&percentComplete_Mod=gte…

…percentComplete=50&percentComplete_Mod=lte…

…description_Mod=isnull…

…description_Mod=notnull…

…name=Workfront&name_Mod=contains…

…entryDate=$$TODAY-7d&entryDate_Range=$$TODAY&entryDate_Mod=between…

Usando instruções OR

É possível aprimorar uma pesquisa adicionando um parâmetro que inclui "OR", bem como um número para indicar o nível de um filtro ou uma série de filtros.

Uma instrução OR retorna somente registros na chamada da API que atendam aos critérios de filtragem da instrução OR. Os filtros não estão implícitos entre níveis de instrução OR.

Por exemplo, se você quiser filtrar por

em seguida, use a seguinte chamada de API com suas várias instruções OR:

GET /attask/api/v15.0/task/search?name=Planning
&name_Mod=contains
&OR:1:portfolio:name=FixedAssets
&OR:1:portfolio:name_Mod=eq
&OR:1:assignedTo:name=Steve
&OR:1:assignedTo:name_Mod=cicontains
&OR:2:parent:name=Final Task
&OR:2:parent:name_Mod=eq

Utilização de parâmetros de filtro

Uma possível armadilha ao usar parâmetros de URL para filtros de pesquisa é que o Workfront analisa determinados parâmetros antes de verificar os diferentes métodos de autenticação (ou seja, nome de usuário, senha, apiKey, cookie). Quando isso acontece, os parâmetros não são usados como filtros na chamada.

Para evitar esse problema, você pode colocar esses valores em parâmetros de filtro com formatação JSON. Por exemplo, se você deseja filtrar pelo nome de usuário testuser, em vez de usar

/attask/api/v15.0/user/search?username=testuser@workfront.com

/attask/api/v15.0/user/search?filters={"username":"testuser@workfront.com"}

Usando o parâmetro de solicitação Map

Por padrão, os dados retornados de uma pesquisa são uma matriz JSON. Dependendo do caso de uso, pode ser mais eficiente obter o resultado como um objeto JSON indexado pela ID. Isso pode ser feito usando o parâmetro de solicitação map. Por exemplo, a solicitação

/attask/api/v15.0/task/search?map=true

{
    "data": {
        "4c9a97db0000000f13ee4446b9aead9b": {
            "percentComplete": 0,
            "status": "NEW",
            "name": "first task",
            "ID": "4c9a97db0000000f13ee4446b9aead9b",
            "taskNumber": 1 
        },
        "4ca28ba600002024cd49e75bd43cf601": {
            "percentComplete": 0,
            "status": "INP:A",
            "name": "second task",
            "ID": "4ca28ba600002024cd49e75bd43cf601",
            "taskNumber": 2 
        } 
    } 
}

Uso do parâmetro de solicitação de campos

Por padrão, a recuperação de um objeto retorna apenas o subconjunto de campos mais comumente usado.

Você pode usar o parâmetro de solicitação de campos para especificar uma lista separada por vírgulas de campos específicos a serem retornados. Por exemplo, a solicitação

/attask/api/v15.0/task/search?fields=plannedStartDate,priority

{
    "priority": 2,
    "name": "first task",
    "ID": "4c7c08fa0000002ff924e298ee148df4",
    "plannedStartDate": "2010-08-30T09:00:00:000-0600" 
}

Para obter uma lista de possíveis referências de campo, consulte o API Explorer

Pesquisando objetos aninhados

Você pode pesquisar objetos aninhados. Por padrão, objetos aninhados são retornados somente com o nome e a ID. Por exemplo, para obter todas os problemas junto com seus proprietários, use a seguinte solicitação:

/attask/api/v15.0/issue/search?fields=owner

/attask/api/v15.0/issue/search?fields=owner:title,owner:phoneNumber

{
    "name": "an important issue",
    "ID": "4c78285f00000908ea8cfd66e084939f",
    "owner": {
        "title": "Operations Specialist",
        "phoneNumber": "555-1234",
        "name": "Admin User",
        "ID": "4c76ed7a0000054c172b2c2d9f7f81c3" 
    } 
}

Recuperando coleções aninhadas

Você pode recuperar coleções aninhadas de objetos. Por exemplo, para obter um projeto com todas as suas tarefas, use a seguinte solicitação:

/attask/api/v15.0/project/search?fields=tasks

/attask/api/v15.0/task/search?fields=assignments

Pesquisa de vários campos aninhados

Por padrão, apenas o nome e a ID de cada tarefa são retornados, mas campos aninhados adicionais podem ser especificados com a sintaxe de dois pontos. Para visualizar todos os campos disponíveis para um objeto ou coleção relacionados, basta acrescentar dois pontos e um asterisco à referência do objeto/coleção.

/attask/api/v15.0/task/search?fields=assignments:*

Recuperar dados personalizados

Você pode recuperar campos de dados personalizados usando o prefixo “DE:”. Por exemplo, para solicitar um projeto com um parâmetro chamado "CustomText", use a seguinte solicitação:

/attask/api/v15.0/project/search?fields=DE:CustomText

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    "DE:CustomText": "task b" 
}

/attask/api/v15.0/project/search?fields=parameterValues

{
    "name": "custom data project",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    parameterValues: { 
        "DE:CustomText": "task b", 
        "DE:CustomNumber": 1.4, 
        "DE:CustomCheckBoxes": ["first", "second", "third"] 
    } 
}

Uso de consultas nomeadas

Alguns tipos de objeto possuem pesquisas nomeadas que são comumente executadas e estão disponíveis ao anexar o nome da consulta ao final do URI do tipo de objeto. Por exemplo, a seguinte solicitação recupera os itens de trabalho (tarefas e problemas) aos quais o usuário está atualmente atribuído:

/attask/api/v15.0/work/myWork

Usando Count

Você pode usar count para retornar o número de resultados que correspondem à sua consulta. Isso pode ser útil quando você não precisa dos dados nos resultados. Ao retornar apenas a contagem, o servidor pode processar a solicitação mais rapidamente e economizar largura de banda. Por exemplo, a solicitação

GET /attask/api/v15.0/project/count?status=CUR

{
    "count": 3 
}

Solicitar um relatório

Você pode realizar uma solicitação de relatório, na qual apenas o agregado de algum campo é desejado com um ou mais agrupamentos. Conforme mostrado no exemplo a seguir, a sintaxe do relatório é a mesma que a sintaxe da API SOAP:

GET /attask/api/v15.0/hour/report?project:name_1_GroupBy=true&hours_AggFunc=sum

{
    "First Project": { 
        "sum_hours": 15 
    }, 
     "Second Project": { 
        "sum_hours": 30 
    } 
}

{
    "First Project": { 
        "sum_hours": 15 
    }, 
    "Second Project": { 
        "sum_hours": 30 
    }, 
    "$$ROLLUP": { 
        "sum_hours": 45 
    } 
}

Classificação dos resultados da consulta na API

Você pode classificar seus resultados por qualquer campo se acrescentar o seguinte à sua chamada de API:

&entryDate_Sort=asc

Por exemplo, se você deseja classificar por data inicial planejada da tarefa, remova entryDate e substitua-a por plannedCompletionDate.

Isso funciona para a maioria dos campos no Workfront.

Consideração dos limites de consulta

Ao consultar um objeto, deve-se levar em consideração a relação entre objetos relacionados e as limitações de pesquisa. Por exemplo, conforme mostrado na tabela a seguir, uma consulta por projetos pode retornar no máximo 2.000 projetos. Esses 2.000 projetos são considerados “objetos primários”. Se você consultar o campo Tarefas nos projetos, o campo Tarefas, que é uma coleção, se torna um objeto secundário ao objeto primário Projeto. Uma consulta para o campo Tarefas pode incluir milhares de tarefas em projetos. No total, o número combinado de objetos (projetos e tarefas) retornados não pode exceder o máximo de 50.000.

Para garantir um desempenho ideal, a tabela a seguir mostra as limitações impostas às solicitações de pesquisa.

Utilização de respostas paginadas using-paginated-responses

Para substituir a limitação da consulta Número padrão de resultados e permitir 200 resultados, você pode incluir o filtro $$LIMIT=200 na sua consulta, conforme mostrado no exemplo a seguir:

GET /attask/api/v15.0/project/search?$$LIMIT=200

Para garantir a confiabilidade e o desempenho para outros locatários no sistema, o limite máximo permitido de resultados por consulta é de 2.000 objetos. Tentar especificar um limite maior resultará em uma mensagem de erro IllegalArgumentException.

Portanto, recomendamos que você considere o uso de respostas paginadas para grandes conjuntos de dados. Para especificar o primeiro resultado que deve ser retornado, adicione o filtro $$FIRST. Por exemplo, a solicitação a seguir retorna os resultados 201–250 para uma consulta:

GET /attask/api/v15.0/project/search?$$FIRST=200&$$LIMIT=50

Observe que, no exemplo acima, $$FIRST=200 retorna o 201º resultado. $$FIRST=0 retornaria o primeiro resultado. Pode ser útil pensar no valor $$FIRST como o número de resultados que você deseja ignorar antes de retornar os resultados.

Para garantir que seus resultados sejam paginados corretamente, use um parâmetro de classificação. Isso permite que os resultados sejam retornados na mesma ordem, para que a paginação não repita ou pule resultados. Por exemplo, para classificar usando a ID do objeto, use ID_Sort=asc.

Criar uma regra de acesso

Você pode criar uma regra de acesso para determinar quem pode acessar um objeto. A seguir estão exemplos de regras de acesso que você pode definir:

Para definir um projeto para que seja compartilhado apenas com um usuário com o ID "abc123", use a seguinte solicitação:

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=put &updates={ accessRules: [ {accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'} ] }

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?method=put&accessorID=abc123&accessorObjCode=USER&coreAction=VIEW

GET /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?fields=accessRules:*

Comportamento POST

POST insere um novo objeto. A sintaxe é idêntica à do PUT, mas com algumas exceções. Como o novo objeto ainda não existe, ele não possui uma ID. Por esse motivo, o URI não inclui a ID.

Criar um objeto

A seguir, um exemplo de solicitação para criar um novo projeto:

POST /attask/api/v15.0/project?name=New Project

Copiar um objeto

Alguns objetos podem ser copiados. Para esses tipos de objeto, é possível criar novos objetos fazendo uma postagem com um parâmetro copySourceID. Por exemplo, a seguinte solicitação copia o projeto especificado e atribui a ele um novo nome:

POST /attask/api/v15.0/project?copySourceID=4c7...&name=Copied Project

Fazer upload de documentos

Você pode fazer upload de documentos através da seguinte URL da API:

POST /attask/api/v15.0/upload

{
    "handle": "4c7c08fa0000002ff924e298ee148df4"
}

POST /attask/api/v15.0/document?updates={
    name: aFileName,
    handle: abc...123, (handle from the file upload)
    docObjCode: PROJ, (or TASK, OPTASK, etc)
    objID: abc...123,
    currentVersion:{version:v1.0,fileName:aFileName}
}

Comportamento PUT

PUT é usado para atualizar um objeto.

A resposta de uma PUT é idêntica a uma GET. Em ambos os casos, o servidor retorna o novo estado do objeto após a atualização. Todas as regras utilizadas para alterar uma resposta a uma solicitação GET também funcionam com PUT, como especificar campos adicionais a serem retornados, dados personalizados e assim por diante.

Editar objetos

As atualizações dos objetos são sempre feitas por meio de IDs, utilizando o URI exclusivo do objeto. Os campos a serem atualizados são especificados como parâmetros de solicitação. Por exemplo, para alterar o nome de um projeto, você poderia enviar uma solicitação semelhante à seguinte:

PUT /attask/api/v15.0/project/4c7...?name=Novo nome do projeto 
PUT /attask/api/v15.0/project?id=4c7...&name=Novo nome do projeto

Especificar edições em JSON

Conforme mostrado no exemplo a seguir, você pode usar o parâmetro de solicitação de atualizações para especificar os campos a serem atualizados usando a sintaxe JSON:

PUT /attask/api/v15.0/project/4c7...?updates= 
{
     nome: "Novo Nome de Projeto", 
     status: "CUR", 
     ... 

Fazer atualizações aninhadas

Alguns objetos possuem coleções particulares que podem ser atualizadas. O exemplo a seguir demonstra como substituir as atribuições existentes para uma determinada tarefa:

PUT /attask/api/v15.0/task/4c7...?updates= 
{
    atribuições: [ 
        { 
            assignedToID: "2222...54d0, 
            assignmentPercent: 50.0 
        },{ 
            roleID: "1111...54d0"
        } 
    ] 

O exemplo a seguir transforma um projeto em uma fila pública de suporte técnico. Observe que as propriedades da fila já existente são substituídas.

PUT /attask/api/v15.0/project/4c7...?updates= 
{ 
    queueDef: { 
        isPublic: 1 
    } 
}

Usar o parâmetro de solicitação de ação

Alguns objetos aceitam ações adicionais que podem ser realizadas além de edições simples. Você pode especificar essas ações usando o parâmetro de solicitação de ação. Por exemplo, a seguinte solicitação recalcula o cronograma de um determinado projeto:

PUT /attask/api/v15.0/project/4c7...?action=calculateTimeline

ou

PUT /attask/api/v15.0/project/4c7.../calculateTimeline 

Mover objetos

A seguir, é demonstrada a sintaxe para mover uma tarefa de um projeto para outro:

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

PUT /attask/api/v15.0/project/1234/approveApproval

PUT /attask/api/v15.0/project/1234/calculateFinance

PUT /attask/api/v15.0/project/1234/calculateTimeline

PUT /attask/api/v15.0/project/1234/calculateDataExtension

PUT /attask/api/v15.0/project/1234/recallApproval

PUT /attask/api/v15.0/project/1234/rejectApproval

PUT /attask/api/v15.0/task/1234/move

PUT /attask/api/v15.0/workitem/1234/markViewed

A seguir, apresentamos um exemplo de cada tipo de ação:

PUT /attask/api/v15.0/project/1234?method=put&updates={accessRules:[{accessorID: 'abc123', accessorObjCode: 'USER', coreAction: 'VIEW'}]}

Compartilhar objetos

O exemplo a seguir demonstra a sintaxe para compartilhar um projeto com uma equipe:

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx/share?accessorID=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx&accessorObjCode=TEAMOB

PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxxxxxx?method=PUT&updates={accessRules:[{accessorID:'123abcxxxxxxxxxxxxxxxxxxxxxxxxxx',accessorObjCode:'TEAMOB',coreAction:'VIEW'}]}

PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...

Comportamento DELETE

DELETE remove um objeto. Em todos os casos, a URI pode incluir o parâmetro force=true para fazer com que o servidor remova os dados especificados e seus dependentes. No exemplo a seguir, uma tarefa é excluída executando o método DELETE do HTTP em um URI:

DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0 
DELETE /attask/api/v15.0/task/4c78821c0000d6fa8d5e52f07a1d54d0?force=true 
DELETE /attask/api/v15.0/task?id=4c78821c0000d6fa8d5e52f07a1d54d0?force=true

Atualizações em massa

Uma instrução de atualização em massa atualiza vários objetos ao mesmo tempo em uma única chamada de API. Uma chamada de API de criação em massa é criada de forma semelhante a uma chamada de atualização normal, conforme mostrado nos exemplos a seguir:

PUT /attask/api/v15.0/proj?updates=[{"name":"Test_Project_1"},{"name":"Test_Project_2"}]&method=POST&apiKey=123ab-cxxxxxxxxxxxxxxxxxxxxxxxxxx

PUSH /attask/api/v15.0/proj?updates=[{"name":"Test_Project_1"},{"name":"Test_Project_2"}]&method=POST&apiKey=123ab-cxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [{
    ID: "53ff8d3d003b438b57a8a784df38f6b3",
    name: "Test_Project_1",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
},
{
    ID: "53ff8d49003b43a2562aa34eea3b6b10",
    name: "Test_Project_2",
    objCode: "PROJ",
    percentComplete: 0usi,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:12:00:000-0400",
    status: "CUR"
}]

PUT /attask/api/v15.0/proj?Umethod=PUT&updates=[{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_1_ Edit"},{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_2_Edit"}]&apiKey=123abcxxxxxxxxxxxxxxxxxxxxxxxxxx

data: [ {
     ID: "53ff8e15003b461d4560f7f65a440078",
     name: "Test_Project_1_Edit",
     objCode: "PROJ",
     percentComplete: 0,
     plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
     plannedStartDate: "2014-08-28T11:00:00:000-0400",
     priority: 0,
     projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
     status: "CUR"
},
{
    ID: "53ff8e19003b46238a58d303608de502",
    name: "Test_Project_2_Edit",
    objCode: "PROJ",
    percentComplete: 0,
    plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
    plannedStartDate: "2014-08-28T11:00:00:000-0400",
    priority: 0,
    projectedCompletionDate: "2014-08-28T16:16:00:000-0400",
    status: "CUR"
}]