API Design

Authentise 3DIAX can be used as a RESTful data-backbone, as individual modules, or as a unified system. This page explains the basic design concepts of the system, so developers can better understand general design ideas.

Raw API Interface

Our services and settings, as broadly as we can, are available via direct RESTful <https://en.wikipedia.org/wiki/Representational_state_transfer> API. You can log directly into the Raw API via <http://data.authentise.com>, and run example calls or sample code directly against the server, once you have an account.

RESTful Design

Our RESTful <https://en.wikipedia.org/wiki/Representational_state_transfer> design is based off a comment set of patterns. The core of the design is having a core URL for each kind of Resource, and then a unique ID for each instance of that resource. Each Resource has a standard JSON formated for the set of data, which the endpoint can read, write, or update.

data.authentise.com/RESOURCE/

This is an example of a Resource in 3DIAX. This example Resource is named RESOURCE . Doing a standard HTTPS OPTION on this endpoint will return data about the JSON format, to see what values or options the resource accepts.

HTTPS POST: To create a new resource in the system, a users can also POST to this endpoint, with the json structure described in the OPTION reply. This will create a new entry, with a unique UUID, and return the new resources URL in the headers as ‘X-Location’ of the new resource.

HTTPS GET/HTTS LIST : To list all resources in the system, a user can GET to this endpoint. It will return a listicle structure, which contains pagination settings, as well as a list of as many RESOURCE objects as it can. In our documentation, this is often referenced as doing an``HTTPS LIST``. There is an example of this in @Far TBD

NOTE: if you accidentally go to data.authentise.com/RESOURCE, you will be re-directed to this URL.

data.authentise.com/RESOURCE/UUID-PER-RESOURCE/
This is an example of the URI for a single Resource Instance. This is a specific entry of a resource, created by a user posting to RESOURCE, or by a back-end data process.

HTTPS GET: This will return a JSON dict of the data for this Resource Instance. Note that some of the settings in this GET are more data than received on the HTTPS LIST on the Resource Endpoint. This is by design, see HTTPS OPTIONS results to see what is in a GET vs a LIST call.

HTTPS PUT: This is used to update a value in the Resource Instance. You only need to PUT the value you want to update, you should not re-put the whole entry received from a HTTPS GET, since some entries are read-only, such as Last Update Time.

Resource Example:

A good, practical example of this layout can be see in the Model/Line-Item/Order relationship. This section will describe that relationship in detail, as a first example. More details on each endpoint is avaible in our Git Repo <https://github.com/Authentise/Example-Authentise-Session>

Model:
This resource contains the actual design file, and information about the file, it’s geometry, name, and orientation
Line-Item:
This resource contains the details about manufacturing. Manufacturing steps, count of number of instances of a model to manufacture, material, verification steps.
Order:
This contains the details about the deliverable, groups of related items, and due dates.
Image of Resource layout in layers

Non-standard install URL’s

All of our API’s are available via URL at data.$SITE_NAME (where $SITE_NAME can be a custom domain name). For cloud users, this is <https://data.authentise.com> All of our documentation in this guide is based this off the data.authentise.com site. If you have a local install, you will need to replace the authentise.com in all examples, with your own site name.