Conceptos básicos de API

La meta de la API de Adobe Workfront es simplificar la creación de integraciones con Workfront mediante la introducción de una arquitectura REST-ful que funcione a través de HTTP. En este documento se da por hecho que está familiarizado con las respuestas de REST y JSON, y se describe el método que utiliza la API de Workfront.

Ser conocedor del esquema de Workfront le ayudará a comprender las relaciones de la base de datos que se pueden utilizar para extraer datos de Workfront con fines de integración.

Límites y directrices

Para garantizar un rendimiento coherente del sistema bajo demanda de Workfront, la API de Workfront limita los subprocesos simultáneos de la API. Este mecanismo de protección evita problemas del sistema causados por llamadas a la API abusivas. El entorno de zona protegida tiene el mismo límite de subprocesos simultáneos de la API, lo que permite a los clientes y socios probar las llamadas a la API con precisión antes de lanzar un código a producción.

Para entornos de producción, previsualización y pruebas de unidades, las solicitudes de los usuarios finales tienen una longitud del URI máxima de 8892 bytes, ya que se enrutan a través de la CDN de Workfront (Akamai). Este límite solo se aplica a los URI que se enrutan a través de la CDN.

Descargo de responsabilidad

Cualquier uso de la API debe probarse en un entorno beta de Workfront antes de ejecutarse en el entorno de producción. Si algún cliente utiliza la API para un proceso que Workfront considera razonablemente intenso para el software bajo demanda (es decir, el proceso causa un efecto sustancialmente negativo en el rendimiento del software para otros clientes), Workfront se reserva el derecho de solicitar que el cliente interrumpa ese proceso. Si el cliente no cumple y el problema persiste, Workfront se reserva el derecho de finalizar el proceso.

URL de la API de Workfront

Para obtener más información acerca de la dirección URL que usará para llamar a la API de Workfront, vea Formato de dominio para llamadas a la API de Adobe Workfront.

Conceptos básicos de REST

Esta sección proporciona una introducción de alto nivel sobre cómo interactuar con la API de REST de Workfront para los siguientes principios de REST:

URI de objeto

A cada objeto del sistema se le asigna un URI único que consta del tipo de objeto y el ID. Los siguientes ejemplos muestran algunas URI que describen tres objetos únicos:

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

El tipo de objeto no distingue entre mayúsculas y minúsculas y puede ser el ObjCode abreviado (como proj) o el nombre de objeto alternativo (proyecto).

Para obtener una lista de objetos, códigos de objeto válidos y campos de objeto, consulte  Explorador de API.

Operaciones

Los objetos se manipulan enviando una petición HTTP a su URI único. La operación que se va a realizar se especifica mediante el método HTTP.

Los métodos HTTP estándar corresponden a las siguientes operaciones:

Para evitar deficiencias de cliente o límites de longitud de protocolo, se puede utilizar el parámetro de método para anular el comportamiento HTTP. Por ejemplo, se puede implementar una operación de GET publicando el siguiente URI:

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

Respuesta

Cada solicitud recibe una respuesta en formato JSON. La respuesta tiene un atributo de datos si la solicitud se realizó correctamente o un atributo de error si hubo un problema. Por ejemplo, la solicitud

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

devuelve una respuesta JSON similar a la siguiente:

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

Se ha añadido seguridad especial en torno a las peticiones PUT, POST y DELETE. Cualquier solicitud que resulte de la escritura o eliminación en la base de datos solo se puede ejecutar si sessionID=abc123 está incluido en el URI. Los siguientes ejemplos muestran el aspecto que tendría esto para una petición DELETE:

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

Autenticación

La API autentica todas las solicitudes para garantizar que el cliente tenga acceso para ver o modificar el objeto solicitado.

La autenticación se realiza pasando un ID de sesión, el cual se puede proporcionar mediante uno de los métodos siguientes:

Autenticación del encabezado de la solicitud

El método de autenticación preferido es pasar un encabezado de solicitud denominado SessionID que contenga el token de sesión. Esto tiene la ventaja de estar protegido contra ataques de falsificación de solicitud en sitios múltiples (CSRF) y de no interferir con el URI con fines de almacenamiento en caché.

A continuación se muestra un ejemplo de encabezado de solicitud:

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

Autenticación basada en cookies

La API utiliza la misma autenticación basada en cookies que la IU web utiliza el sistema. En el que, si un cliente inicia sesión en Workfront mediante la interfaz de usuario web, cualquier llamada AJAX realizada desde el mismo explorador utiliza la misma autenticación.

Inicio de sesión

Si utiliza un nombre de usuario y una contraseña válidos, puede utilizar la siguiente solicitud para obtener un ID de sesión:

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

Esto establece una cookie para autenticar solicitudes futuras, así como para devolver una respuesta JSON con el ID de sesión recién creado, el ID de usuario del usuario que ha iniciado sesión y otros atributos de sesión.

Generación de una clave de API

Puede generar una clave de API al iniciar sesión en el sistema como ese usuario, tal como se muestra en el siguiente ejemplo:

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

Recuperación de una clave de API generada anteriormente

También puede recuperar una clave de API que se haya generado anteriormente para un usuario en particular ejecutando getApiKey:

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

Puede utilizar este resultado para autenticar cualquier llamada de API añadiendo "apiKey" como el parámetro de solicitud con este valor en lugar de un ID de sesión o un nombre de usuario y contraseña. Esto es beneficioso desde el punto de vista de la seguridad.

La siguiente solicitud es un ejemplo de recuperación de datos de un proyecto mediante apiKey:

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

Invalidar una clave de API

Si el valor de apiKey se ha visto comprometido, puede ejecutar "clearApiKey" para invalidar la clave de API actual, tal como se muestra en el siguiente ejemplo:

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

Una vez borrada, puede volver a ejecutar getApiKey para generar una nueva clave de API.

Cerrar sesión

Cuando finaliza una sesión, puede utilizar la siguiente solicitud para cerrar la sesión del usuario, lo cual impide que se siga accediendo con el ID de sesión.

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

El ID de sesión que se va a cerrar se puede especificar como cookie, encabezado de solicitud o parámetro de solicitud.

Para cerrar la sesión de un usuario:

Siempre debe incluir el ID de sesión proporcionado después del inicio de sesión al realizar peticiones PUT, POST y DELETE.

El comportamiento de GET

Utilice el método HTTP GET para recuperar uno o varios objetos y ejecutar informes.

Recuperación de objetos

Se puede mejorar la búsqueda de objetos mediante modificadores y filtros.

Recuperación de un objeto mediante el ID de objeto

Si conoce el ID de un objeto, puede recuperar el objeto accediendo a su URI único. Por ejemplo, la solicitud

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

devuelve una respuesta similar a la siguiente:

{
    "percentComplete": 0,
    "estado": "CUR",
    "prioridad": 2,
    "nombre": "Proyecto completamente nuevo",
    "ID": "4c7c08b20000002de5ca1ebc19edf2d5" 
}

Para recuperar varios objetos en la misma solicitud, especifique el parámetro de solicitud de ID y proporcione una lista de ID separados por comas, como se muestra en el siguiente ejemplo:

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

Observe que la solicitud /attask/api/v15.0/project?id=… es la misma que la solicitud /attask/api/v15.0/project/....

Recuperación de un objeto mediante el URI

Si desea recuperar un objeto mediante criterios distintos al ID, puede buscar el URI.

Por ejemplo, puede utilizar la siguiente solicitud para devolver una lista de todos los proyectos del sistema:

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

Puede especificar filtros utilizando los parámetros de solicitud como pares de nombre-valor. Por ejemplo, el siguiente ejemplo muestra una solicitud que buscaría todos los proyectos actuales:

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

La siguiente solicitud encuentra todas las tareas que aún no se han completado y que se han asignado a un usuario llamado John.

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

Uso de modificadores de búsqueda

En la tabla siguiente se enumeran algunos de los modificadores que puede utilizar con la API de Workfront.

…status=cls&status_Mod=eq…

…status=cls&status_Mod=ne…

…percentComplete=50&percentComplete_Mod=get…

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

Uso de instrucciones OR

Puede mejorar una búsqueda añadiendo un parámetro que incluya "OR", así como un número, para indicar el nivel de un filtro o una serie de filtros.

Una instrucción OR devuelve únicamente los registros de la llamada a la API que cumplen los criterios de filtrado de la instrucción OR. Los filtros no están implícitos en todos los niveles de instrucción OR.

Por ejemplo, si desea filtrar por

a continuación, utilice la siguiente llamada de API con sus diferentes instrucciones 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

Uso de parámetros de filtro

Un posible inconveniente del uso de parámetros de URL para los filtros de búsqueda es que Workfront analiza ciertos parámetros antes de comprobar si hay diferentes métodos de autenticación (por ejemplo: nombre de usuario, contraseña, apiKey o cookie). Cuando esto suceda, los parámetros no se utilizarán como filtros en la llamada.

Para evitar este problema, coloque estos valores en parámetros de filtro con formato JSON.  Por ejemplo, si quisiera filtrar por el usuario usuariodeprueba, en lugar de utilizar

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

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

Uso del parámetro de solicitud de asignación

De forma predeterminada, los datos devueltos por una búsqueda son una matriz JSON. Según el caso de uso, podría ser más eficaz obtener el resultado como objeto JSON indexado por ID. Esto se puede hacer utilizando el parámetro de solicitud de asignación. Por ejemplo, la solicitud

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

{
    "datos": {
        "4c9a97db0000000f13ee4446b9aead9b": {
            "percentComplete": 0,
            "estado": "NUEVO",
            "nombre": "primera tarea",
            "ID": "4c9a97db0000000f13ee4446b9aead9b",
            "taskNumber": 1 
        },
        "4ca28ba600002024cd49e75bd43cf601": {
            "percentComplete": 0,
            "estado": "INP:A",
            "nombre": "segunda tarea",
            "ID": "4ca28ba600002024cd49e75bd43cf601",
            "taskNumber": 2 
        } 
    } 
}

Uso del parámetro de solicitud de campos

De forma predeterminada, la recuperación de un objeto devolverá solo el subconjunto de campos más utilizado.

Use el parámetro de solicitud de campos para especificar que se devuelva una lista separada por comas de campos específicos. Por ejemplo, la solicitud

/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 obtener una lista de posibles referencias de campo, consulte la API Explorer

Búsqueda de objetos anidados

Es posible buscar objetos anidados. De forma predeterminada, los objetos anidados solo se devuelven con el nombre y el ID. Por ejemplo, para obtener todos los problemas junto con sus propietarios, utilice la siguiente solicitud:

/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" 
    } 
}

Recuperación de colecciones anidadas

Es posible recuperar colecciones anidadas de objetos. Por ejemplo, para obtener un proyecto con todas sus tareas, utilice la siguiente solicitud:

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

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

Buscar varios campos anidados

De forma predeterminada, solo se devuelve el nombre y el ID de cada tarea, pero se pueden especificar campos anidados adicionales con sintaxis de dos puntos. Para ver todos los campos disponibles para un objeto o colección relacionado, simplemente añada dos puntos y un asterisco a la referencia de objeto o colección.

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

Recuperación de datos personalizados

Es posible recuperar campos de datos personalizados con el prefijo “DE:”. Por ejemplo, para solicitar un proyecto con un parámetro llamado “TextoPersonalizado”, utilice la siguiente solicitud:

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

{
    "nombre": "proyecto de datos personalizados",
    "ID": "4c9a954f0000001afad0687d7b1b4e43",
    "DE:CustomText": "tarea 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 con nombre

Algunos tipos de objetos tienen búsquedas con nombre que se ejecutan habitualmente y están disponibles añadiendo el nombre de la consulta al final del URI del tipo de objeto. Por ejemplo, la siguiente solicitud recuperará los elementos de trabajo (tareas y problemas) a los que esté asignado el usuario en ese momento:

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

Uso de Count

Es posible usar count para devolver el número de resultados que coincida con su consulta. Esto resultará útil cuando no se necesiten los datos en los resultados. Al devolver solo el recuento, el servidor podrá procesar la solicitud más rápidamente y ahorrar ancho de banda. Por ejemplo, la solicitud

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

{
    "count": 3 
}

Solicitar un informe

Es posible realizar una solicitud de informe donde solo se desee el acumulado de algún campo con una o más agrupaciones. Tal y como se muestra en el ejemplo siguiente, la sintaxis del informe es la misma que la de la API de 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 
    } 
}

Ordenar los resultados de consulta en la API

Puede ordenar los resultados por cualquier campo si anexa lo siguiente a la llamada de API:

&entryDate_Sort=asc

Por ejemplo, si desea ordenar por fecha de inicio planificada de la tarea, elimine entryDate y reemplácelo por plannedCompletionDate.

Esto funcionará para la mayoría de los campos de Workfront.

Consideración de límites de consulta

Al consultar objetos, se debe tener especial consideración con respecto a la relación de los objetos relacionados y las limitaciones de búsqueda. Por ejemplo, como se muestra en la tabla siguiente, una consulta de proyectos no puede devolver más de 2000 proyectos. Estos 2000 proyectos se consideran “objetos primarios”. Al consultar el campo Tareas en los proyectos, el campo Tareas, que es una colección, se convertirá en un objeto secundario del objeto principal Proyecto. Una consulta para el campo Tareas puede incluir miles de tareas en proyectos. En total, el número combinado de objetos (proyectos y tareas) devueltos no puede superar el máximo de 50 000.

Para garantizar un rendimiento óptimo, la siguiente tabla muestra las limitaciones impuestas a las solicitudes de búsqueda.

Uso de respuestas paginadas using-paginated-responses

Para anular la limitación de la consulta Número predeterminado de resultados y permitir 200 resultados, incluya el filtro $$LIMIT=200 en la consulta, tal y como se muestra en el ejemplo siguiente:

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

Para garantizar la fiabilidad y el rendimiento de otros inquilinos del sistema, el límite máximo de resultados permitidos por consulta es de 2000 objetos. Si se intentase especificar un límite mayor, aparecerá un mensaje de error de IllegalArgumentException.

Por lo tanto, se recomienda considerar la posibilidad de utilizar respuestas paginadas para conjuntos de datos grandes. Para especificar qué primer resultado se devolverá, añada el filtro $$FIRST. Por ejemplo, la siguiente solicitud devuelve los resultados 201-250 de una consulta:

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

Observe que en el ejemplo anterior, $$FIRST=200 devuelve el resultado 201. $$FIRST=0 devolverá el primer resultado. Puede ser útil considerar el valor $$FIRST como el número de resultados que desea omitir antes de devolver los resultados.

Para asegurarse de que los resultados estén correctamente paginados, utilice un parámetro de ordenación. Esto permite que los resultados se devuelvan en el mismo orden, para que la paginación no se repita ni omita resultados. Por ejemplo, para ordenar usando el identificador de objeto, use ID_Sort=asc.

Creación de una regla de acceso

Puede crear una regla de acceso para determinar quién puede acceder a un objeto. Los siguientes son ejemplos de reglas de acceso que puede establecer:

Para configurar un proyecto de modo que se comparta únicamente con un usuario con el ID “abc123”, utilice la siguiente solicitud:

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

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

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

Comportamiento de POST

POST inserta un nuevo objeto. La sintaxis es idéntica a PUT, pero con algunas excepciones. Dado que el nuevo objeto aún no existe, no tiene un ID. Por este motivo, el URI no incluye el ID.

Creación de un objeto

A continuación se muestra un ejemplo de una solicitud para crear un nuevo proyecto:

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

Copia de un objeto

Algunos objetos admiten ser copiados. Para estos tipos de objetos, es posible crear nuevos objetos publicando con un parámetro copySourceID. Por ejemplo, la siguiente solicitud copia el proyecto dado y le asigna un nombre nuevo:

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

Carga de documentos

Puede cargar documentos a través de la siguiente URL de API:

POST /attask/api/v15.0/upload

{
    "handle": "4c7c08fa0000002ff924e298ee148df4"
}

POST /attask/api/v15.0/document?updates={
}    name: aFileName,
    handle: abc...123, (identificador de la carga del archivo)
    docObjCode: PROJ, (o TAREA, OPTASK, etc.)
    objID: abc...123,
    currentVersion:{version:v1.0,fileName:aFileName}

Comportamiento de PUT

PUT se utiliza para actualizar un objeto existente.

La respuesta de PUT es idéntica a GET. En ambos casos, el servidor devuelve el nuevo estado del objeto después de la actualización. Todas las reglas utilizadas para modificar una respuesta a una petición GET también funcionan con PUT, como especificar los campos adicionales que se van a devolver, los datos personalizados, etc.

Edición de objetos

Las actualizaciones de objetos siempre se realizan mediante el ID. utilizando el URI único del objeto. Los campos que se van a actualizar se especifican como parámetros de solicitud. Por ejemplo, para cambiar el nombre de un proyecto puede enviar una solicitud similar a la siguiente:

PUT /attask/api/v15.0/project/4c7...?name=Nuevo nombre de proyecto 
PUT /attask/api/v15.0/project?id=4c7...&name=Nuevo nombre de proyecto

Especificación de ediciones JSON

Como se muestra en el ejemplo siguiente, puede utilizar el parámetro de solicitud de actualizaciones para especificar los campos que se actualizarán con la sintaxis JSON:

PUT /attask/api/v15.0/project/4c7...?updates= 
{
     name: "New Project Name", 
     status: "CUR", 
     ... 
}

Realización de actualizaciones anidadas

Algunos objetos tienen colecciones de propiedad privada que se pueden actualizar. Por ejemplo, en el siguiente ejemplo se muestra cómo sobrescribir las asignaciones existentes de una tarea determinada:

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

El siguiente ejemplo convierte un proyecto en una cola del servicio de asistencia público. Tenga en cuenta que las propiedades de cola existentes se reemplazan.

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

Uso del parámetro de solicitud de acción

Algunos objetos admiten acciones adicionales que se pueden realizar además de ediciones simples. Puede especificar estas acciones mediante el parámetro de solicitud de acción. Por ejemplo, la siguiente solicitud recalcula la línea de tiempo de un proyecto determinado:

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

or

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

Mover objetos

A continuación se muestra la sintaxis para mover una tarea de un proyecto a otro:

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/recallApprova

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 continuación se muestra un ejemplo de cada tipo de acción:

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

Compartir objetos

En el siguiente ejemplo se muestra la sintaxis para compartir un proyecto con un equipo:

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

Comportamiento de DELETE

DELETE elimina un objeto. En todos los casos, el URI puede incluir el parámetro force=true para que el servidor elimine los datos especificados y sus dependientes. En el ejemplo siguiente, se elimina una tarea ejecutando el método DELETE HTTP en un 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

Actualizaciones masivas

Una instrucción de actualización en lote actualiza varios objetos al mismo tiempo dentro de una sola llamada de API. Una llamada de API en lote se crea de forma similar a una llamada de actualización normal, tal como se muestra en los ejemplos siguientes:

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

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"
}]