SOAP API design principles

This page can't be edited. | Page History
    Table of contents
    You are currently comparing two old versions - only when you are comparing against the latest version can you revert. Return to version archive.

    Combined revision comparison

    Comparing version 16:25, 18 Oct 2017 by chladek with version 10:08, 19 Oct 2017 by botek.

    ...

    Fair usage policy

    Every atollon integration, which behaves like a logged user (uses atollon session) should not send more than 2 requests in parallel. This helps the atollon to provide quality of service to all users even in peak usage and extensive operations (like copying big sets of data and so on). 

    Updating atollon objects

    There are some principles to understand when working with (or building) atollon API. Understanding of those principles may prevent accidental data loss, so you better bare them in mind.

    1. Before updating atollon object, you need to have valid copy of whole object before updating. Update function typically reads all editable parameters and replace them. That is why you need to send all of them, because otherwise the empty ones would be considered to be deleted.
    2. Some Get methods do not return pure atollon object, but extended one. Typically extended by selected or derived fields from another object. The reason behind is the reduction the of request amount. Good example is GetFolder, which returns primary contact details (name, surname, primary mobile, primary email etc.). Those extended parameters should not be a part of the update request, because server ignores derived fields in update functions (if you send them, they will be ignored anyway).
    3. There are two ways how the relation between two atollon objects is maintained. The selected solution usually depends on the bussiness importance of the relation or the workflow and can be tracked in the Atollon Lagoon, which is etalon of API usage.
      1. Edit ID of related object in update function.
      2. Separate API function call, which creates the relation.  

    ...

    Version from 16:25, 18 Oct 2017

    This revision modified by chladek (Ban)

    ...

    Version as of 10:08, 19 Oct 2017

    This revision modified by botek (Ban)

    ...

    Fair usage policy

    Every atollon integration, which behaves like a logged user (uses atollon session) should not send more than 2 requests in parallel. This helps the atollon to provide quality of service to all users even in peak usage and extensive operations (like copying big sets of data and so on). 

    Updating atollon objects

    There are some principles to understand when working with (or building) atollon API. Understanding of those principles may prevent accidental data loss, so you better bare them in mind.

    1. Before updating atollon object, you need to have valid copy of whole object before updating. Update function typically reads all editable parameters and replace them. That is why you need to send all of them, because otherwise the empty ones would be considered to be deleted.
    2. Some Get methods do not return pure atollon object, but extended one. Typically extended by selected or derived fields from another object. The reason behind is the reduction the of request amount. Good example is GetFolder, which returns primary contact details (name, surname, primary mobile, primary email etc.). Those extended parameters should not be a part of the update request, because server ignores derived fields in update functions (if you send them, they will be ignored anyway).
    3. There are two ways how the relation between two atollon objects is maintained. The selected solution usually depends on the bussiness importance of the relation or the workflow and can be tracked in the Atollon Lagoon, which is etalon of API usage.
      1. Edit ID of related object in update function.
      2. Separate API function call, which creates the relation.  

    ...