Сообщество программистов Autodesk в СНГ :: Чтение элементов в рабочем пространстве

Сообщество программистов Autodesk в СНГ
PLM 360 API
Чтение элементов в рабочем пространстве

13/02/2014

Чтение элементов в рабочем пространстве

Есть два основных способа получения списка элементов в рабочем пространстве. Вы можете использовать конечные точки элементов или конечную точку запроса. В этой статье будут сравниваться и противопоставляться эти вызовы API. (Спойлер предупреждения: Автор отдаёт предпочтение конечной точке запросов)

Конечная точка элементов соответствует стандартному паттерну REST. Вы можете осуществить вызов GET к URL-адресов ( /api/v2/workspaces/{workspaceId}/items). Возвращаемым значением будут все элементы в рабочем пространстве. Возвращаемое значение - это набор объектов Элемент, который предоставляет базовую информацию. Поскольку полезная нагрузка простая, вызов API быстрый.

Во-первых, эти конечные точки выглядят как идеальный способ навигации по рабочим пространствам, но есть несколько больших минусов. Первый - конечная точка будет возвращать удалённые элементы. Это обусловлено тем, что удалённые элементы фактически не удаляются из системы. Вместо этого, они фактически только помечаются как удалённые. Конечная точка не имеет сведений относительно того, какого типа элементы вы желаете получить, так она возвращает как удалённые, так и не удалённые элементы.

Конечная точка элементов также не имеет какой-либо сортировки, либо возможности фильтрации. В большом рабочем пространстве это значимый недостаток. Если вы ищите конкретный элементы, может потребоваться необходимость проверить сотни страниц с целью найти его.

Конечная точка запросов имеется ввиду для предоставления большего контроля над тем, что вы получаете обратно. Это позволяет вам сортировать ваши результаты и позволяет вам фильтровать ваши элементы так, как вы хотите. Есть статья относительно того как делать запросыв онлайн-справке PLM 360. Одним из вариантов использования является фильтрация удалённых элементов и сортировка по имени дескриптора, как в следующем примере JSON.

{
"conditions":[
{
    "propertyDefinition":
    {
      "id":"IS_DELETED",
      "type":"SYSTEM"
    },
    "operator":"EQUALS",
    "value":"false"
}],
    "page":1,
    "pageSize":100,
    "sort":[
    {
      "propertyDefinition":
      {
         "id":"ITEM_DESCRIPTOR",
         "type":"SYSTEM"
      },
     "sortAscending":true
}]
}

Возвращаемое значение - это набор объектов ItemDetail. Он содержит больше данных, чем элемент, но это стоит производительности. На данный момент конечная точка запросов не имеет возможности контролировать, какие части ItemDetail возвращаются. Так, она всегда пытается искать значения полей, права собственности и данные аудита.

Этот вызов немного сложней в работе, так как это POST вызов. Поскольку полезная нагрузка должна быть перезана, глагол GET не может быть использован. Вы не можете это легко проверить в вашем веб-браузере, и сложней перемещаться между страницами.

Хотя конечная точка запроса медленней, она все равно та, которая рекомендуется для использования в ваши приложениях. Гибкость и масштабируемость является обязательным элементом. Вероятно, они будут улучшениями будущего, так что не расстраивайтесь, если он ещё не поддерживает тот тип поиска, который вы хотите. Единственный раз, когда рекомендуется использовать конечную точку, элементов - это выполнение быстрого сканирования всего рабочего пространства.

Источник: http://justonesandzeros.typepad.com/blog/2014/01/reading-the-items-in-a-workspace.html

Обсуждение: http://adn-cis.org/forum/index.php?topic=566

Опубликовано 13.02.2014
Отредактировано 27.02.2014 в 12:47:02