Conceptos básicos de API
El objetivo 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.
Una familiaridad con el 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 de API simultáneos. Esta protección evita problemas del sistema causados por llamadas API abusivas. El entorno de espacio aislado tiene el mismo límite de subprocesos de API simultáneas, lo que permite a los clientes y socios probar las llamadas de API con precisión antes de lanzar el código a producción.
Para entornos de producción, previsualización y prueba de unidades, las solicitudes de los usuarios finales tienen una longitud 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 el 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 gravoso para el software bajo demanda (es decir, el proceso causa un efecto materialmente 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 API de Workfront
Para obtener 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 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 códigos de objeto válidos, consulte Explorador de API.
Operaciones
Los objetos se manipulan enviando una solicitud 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:
- GET: recupera un objeto por identificador, busca todos los objetos mediante una consulta, ejecuta informes o ejecuta consultas con nombre
- POST - Inserta un nuevo objeto
- PUT: edita un objeto existente
- DELETE - Elimina un objeto
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 de
GET /attask/api/v15.0/proj/4c7c08b20000002de5ca1ebc19edf2d5
devuelve una respuesta JSON similar a la siguiente:
{
"datos": [
{
"percentComplete": 0,
"estado": "CUR",
"prioridad": 2,
"nombre": "Proyecto completamente nuevo",
"ID": "4c7c08b20000002de5ca1ebc19edf2d5"
}
]
Se ha agregado seguridad especial en torno a las solicitudes del PUT, el POST y el DELETE. Cualquier solicitud que resulte en 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 solicitud de 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 cada solicitud para garantizar que el cliente tenga acceso para ver o modificar un objeto solicitado.
La autenticación se realiza pasando un ID de sesión que se puede proporcionar mediante uno de los métodos siguientes:
Autenticación de encabezado de 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 a salvo de ataques de falsificación de solicitudes entre sitios (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
Solicitar autenticación de parámetro
Puede autenticarse pasando un parámetro de solicitud denominado sessionID, como se muestra en el siguiente ejemplo:
GET /attask/api/v15.0/project/4c78821c0000d6fa8d5e52f07a1d54d0?sessionID=abc1234
Autenticación basada en cookies
La API utiliza la misma autenticación basada en cookies que la IU web utiliza para configurar el sistema. En el que, si un cliente inicia sesión en Workfront AJAX mediante la interfaz de usuario web, cualquier llamada a la red realizada desde el mismo explorador utiliza la misma autenticación.
Inicio de sesión
/login
ni de las claves API. En su lugar, utilice uno de los siguientes métodos de autenticación:- Autenticación de servidor con JWT
- Autenticación de usuario con OAuth2
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 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.
Generando una clave API
Puede generar una clave API al iniciar sesión en el sistema como ese usuario, como se muestra en el siguiente ejemplo:
PUT /attask/api/v15.0/user?action=generateApiKey&username= username&password=password&method=put
Recuperando 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 agregando "apiKey" como parámetro de solicitud con este valor en lugar de un nombre de usuario y contraseña de sessionID. 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 la apiKey:
GET /attask/api/v15.0/project/abc123xxxxx?apiKey=123abcxxxxxxxxx
Invalidar una clave API
Si el valor de apiKey se ha visto comprometido, puede ejecutar "clearApiKey" que invalida la clave de API actual, 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 ejecutar getApiKey de nuevo 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 que impide que se siga accediendo con el ID de sesión.
GET /attask/api/v15.0/logout?sessionID=abc1234
El sessionID 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:
-
Vaya a la pantalla de inicio de sesión, pero no inicie sesión.
-
Cambie la dirección URL a /attask/api/v15.0/project/search.
Observe que la página no se encuentra. -
Reemplace la palabra search por login?username=admin&password=user, sustituyendo su nombre de usuario y contraseña por admin y *user
*Esta sesión se almacena en el explorador como una cookie y no es necesario reiniciarla en cada solicitud de GET posterior. -
Vuelva a cambiar la dirección URL a /attask/api/v15.0/project/search.
-
Observe la respuesta proporcionada.
Siempre debe incluir el sessionID proporcionado después del inicio de sesión al realizar solicitudes de PUT, POST y DELETE.
Comportamiento de GET
Utilice el método de GET HTTP para recuperar uno o varios objetos y ejecutar informes.
Recuperando 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 de
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 O.
Por ejemplo, si desea filtrar por
- Tareas con un nombre que contenga "Planning" O
- Tareas en un portafolio llamado "FixedAssets" Y asignadas a alguien con un nombre que contenga "Steve" O
- Tareas que tienen una tarea principal llamada "Tarea final"
a continuación, utilice la siguiente llamada de API con sus varias 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, cookie). Cuando esto sucede, los parámetros no se utilizan como filtros en la llamada de.
Para evitar este problema, puede colocar estos valores en parámetros de filtro con formato JSON. Por ejemplo, si desea filtrar por usuario usuario de prueba, en lugar de utilizar
/attask/api/v15.0/user/search?username=testuser@workfront.com
/attask/api/v15.0/user/search?filters={"username":"testuser@workfront.com"}
Uso del parámetro de solicitud de mapa
De forma predeterminada, los datos devueltos por una búsqueda son una matriz JSON. Según el caso de uso, puede ser más eficaz obtener el resultado como un objeto JSON indexado por ID. Esto se puede hacer utilizando el parámetro de solicitud de asignación. Por ejemplo, la solicitud de
/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 devuelve solo el subconjunto de campos más utilizado.
Puede utilizar el parámetro de solicitud de campos para especificar que se devuelve una lista separada por comas de campos específicos. Por ejemplo, la solicitud de
/attask/api/v15.0/task/search?fields=plannedStartDate,priority
{
"prioridad": 2,
"nombre": "primera tarea",
"ID": "4c7c08fa0000002ff924e298ee148df4",
"plannedStartDate": "30T09:00:00:000-0600"
Para obtener una lista de posibles referencias de campo, consulte la Explorador de API
Búsqueda de objetos anidados
Puede 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
{
"nombre": "un problema importante",
"ID": "4c78285f00000908ea8cfd66e084939f",
"propietario": {
"título": "Especialista en operaciones",
"phoneNumber": "555-1234",
"nombre": "Usuario administrador",
"ID": "4c76ed7a0000054c172b2c2d9f7f81c3"
}
Recuperación de colecciones anidadas
Puede 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 agregue 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
Puede recuperar campos de datos personalizados con el prefijo "DE:". Por ejemplo, para solicitar un proyecto con un parámetro llamado "CustomText", utilice la siguiente solicitud:
/attask/api/v15.0/project/search?fields=DE:CustomText
{
"nombre": "proyecto de datos personalizados",
"ID": "4c9a954f0000001afad0687d7b1b4e43",
"DE:CustomText": "tarea b"
}
/attask/api/v15.0/project/search?fields=parameterValues
{
"nombre": "proyecto de datos personalizados",
"ID": "4c9a954f0000001afad0687d7b1b4e43",
parameterValues: {
"DE:CustomText": "tarea b",
"DE:CustomNumber": 1.4,
"DE:CustomCheckBoxes": ["primero", "segundo", "tercero"]
}
Uso de consultas con nombre
Algunos tipos de objeto tienen búsquedas con nombre que se ejecutan normalmente y están disponibles añadiendo el nombre de la consulta al final del URI del tipo de objeto. Por ejemplo, la siguiente solicitud recupera los elementos de trabajo (tareas y problemas) a los que está asignado el usuario actualmente:
/attask/api/v15.0/work/myWork
Usando Count
Puede usar count
para devolver el número de resultados que coincida con su consulta. Esto puede resultar útil cuando no necesita los datos en los resultados. Al devolver solo el recuento, el servidor puede procesar la solicitud más rápidamente y ahorrar ancho de banda. Por ejemplo, la solicitud de
GET /attask/api/v15.0/project/count?status=CUR
{
"count": 3
}
Solicitud de un informe
Puede realizar una solicitud de informe donde solo se desee el agregado de algún campo con una o más agrupaciones. SOAP Como se muestra en el ejemplo siguiente, la sintaxis del informe es la misma que la de la API de la:
GET /attask/api/v15.0/hour/report?project:name_1_GroupBy=true&hours_AggFunc=sum
{
"Primer proyecto": {
"sum_hours": 15
},
"Segundo proyecto": {
"sum_hours": 30
}
{
"Primer proyecto": {
"sum_hours": 15
},
"Segundo proyecto": {
"sum_hours": 30
},
"$$ROLLUP": {
"sum_hours": 45
}
Clasificación de 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 funciona para la mayoría de los campos de Workfront.
Consideración de límites de consulta
Al consultar un objeto, 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 2.000 proyectos se consideran "objetos primarios". Si consulta el campo Tareas de los proyectos, el campo Tareas, que es una colección, se convierte en un objeto secundario del objeto principal Project. 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 los 50 000.
Para garantizar un rendimiento óptimo, la siguiente tabla muestra las limitaciones impuestas a las solicitudes de búsqueda.
Consulte Uso de respuestas paginadas para obtener instrucciones sobre cómo anular esta limitación.
Uso de respuestas paginadas using-paginated-responses
Para anular la limitación de la consulta Número predeterminado de resultados y permitir 200 resultados, puede incluir el filtro $$LIMIT=200
en la consulta, 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 intenta especificar un límite mayor, aparecerá un mensaje de error de IllegalArgumentException
.
Por lo tanto, le recomendamos que considere la posibilidad de utilizar respuestas paginadas para conjuntos de datos grandes. Para especificar el primer resultado que se debe devolver, agregue 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 201st. $$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 del POST
El 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.
Crear 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
Copiar un objeto
Algunos objetos admiten la copia. 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
Cargar documentos
Puede cargar documentos a través de la siguiente URL de API:
POST /attask/api/v15.0/upload
{
"controlador": "4c7c08fa0000002ff924e298ee148df4"
}
POST /attask/api/v15.0/document?updates={
} nombre: aFileName,
identificador: abc...123, (identificador de la carga del archivo)
docObjCode: PROJ, (o TAREA, OPTASK, etc.)
objID: abc...123,
currentVersion:{version:v1.0,fileName:aFileName}
Comportamiento del PUT
El PUT se utiliza para actualizar un objeto existente.
La respuesta de un PUT es idéntica a una 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 solicitud de 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 de 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...?actualizaciones=
{
nombre: "Nuevo nombre de proyecto",
estado: "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...?actualizaciones=
{
asignaciones: [
{
assignedToID: "2222...54d0,
assignmentPercent: 50,0
},{
roleID: "1111...54d0"
}
]
El siguiente ejemplo convierte un proyecto en una cola del servicio de asistencia pública. Tenga en cuenta que las propiedades de cola existentes se reemplazan.
PUT /attask/api/v15.0/project/4c7...?actualizaciones=
{
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 vuelve a calcular la escala de tiempo de un proyecto determinado:
PUT /attask/api/v15.0/project/4c7...?action=calculateTimeline
o
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/TIEMPO_APROBACIÓN
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/123abcxxxxxxxxxxxxxxxxxxxxxxxxx/share?accessorID=123abcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PUT /attask/api/v15.0/project/123abcxxxxxxxxxxxxxxxxxxxxxx?method=PUT&updates={accessRules:[{accessorID:'123abcxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PUT /attask/api/v15.0/task/4c7.../move?projectID=5d8...
Comportamiento del DELETE
El 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 masiva actualiza varios objetos al mismo tiempo dentro de una sola llamada de API. Una llamada de API de creación masiva se crea de forma similar a una llamada de actualización normal, 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
datos: [{
} ID: "53ff8d3d003b438b57a8a784df38f6b3",
nombre: "Test_Project_1",
objCode: "PROJ",
percentComplete: 0,
plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
plannedStartDate: "2014-08-28T11:00:00:000-0400",
prioridad: 0,
projrollmentDate: "2014-08-28T16:12:00:000-0400",
estado: "CUR"
},
{
ID: "53ff8d49003b43a2562aa34eea3b6b10",
nombre: "Test_Project_2",
objCode: "PROJ",
percentComplete: 0usi,
plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
plannedStartDate: "2014-08-28T11:00:00:000-0400",
prioridad: 0,
plannedCompletionDate: "2014-08-28T16:12:00:000-0400",
estado: "CUR"
}]
PUT /attask/api/v15.0/proj?Umethod=PUT&updates=[{"ID":"123abcxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_1_ Edit"},{"ID":"123abcxxxxxxxxxxxxxxxxxxxxxxx","name":"Test_Project_2_Edit"}&api Clave=123abcxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
datos:
ID: "53ff8e15003b461d4560f7f65a440078",
nombre: "Test_Project_1_Edit",
objCode: "PROJ",
percentComplete: 0,
plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
plannedStartDate: "2014-08-28T11:00:00:000-0400",
prioridad: 0,
projrollmentDate: "2014-08-28T16:16:00:000-0400",
estado: "CUR"
},
{
ID: "53ff8e19003b46238a58d303608de502",
nombre: "Test_Project_2_Edit",
objCode: "PROJ",
percentComplete: 0,
plannedCompletionDate: "2014-08-28T11:00:00:000-0400",
plannedStartDate: "2014-08-28T11:00:00:000-0400",
prioridad: 0,
plannedCompletionDate: "2014-08-28T16:16:00:000-0400",
estado: "CUR"
}]