{"__v":0,"_id":"588f722bbcace50f0052b9e9","category":{"version":"588f722bbcace50f0052b9e1","project":"565f5fa26bafd40d0030a064","_id":"588f722bbcace50f0052b9e2","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-12-03T19:46:10.966Z","from_sync":false,"order":0,"slug":"introduction","title":"Getting Started"},"parentDoc":null,"project":"565f5fa26bafd40d0030a064","user":"565f3941ea46251700972783","version":{"__v":1,"_id":"588f722bbcace50f0052b9e1","project":"565f5fa26bafd40d0030a064","createdAt":"2017-01-30T17:04:43.410Z","releaseDate":"2017-01-30T17:04:43.410Z","categories":["588f722bbcace50f0052b9e2","588f722bbcace50f0052b9e3","588f722bbcace50f0052b9e4","588f722bbcace50f0052b9e5","588f722bbcace50f0052b9e6","588f722bbcace50f0052b9e7"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"5.3.0","version":"5.3.0"},"updates":["57ea87a71ac5b01900de38ad"],"next":{"pages":[],"description":""},"createdAt":"2015-12-08T19:40:59.652Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":1,"body":"## API\nAn API represents a collection of related calls.  Each call is a Proxy Endpoint that consists of either JavaScript logic only, or proxies the request to one or more Remote Endpoints.\n \n## Environments\nEnvironments enable you to maintain multiple sets of session settings and variables. For example, you may have a “development” environment that contains settings and variables which are different from your “test” and  “production” environments. Environment variables can be referred to within JavaScript code in the Proxy Endpoint. At least one Environment has to exist, and a “Development” Environment is created by default.\n \n## Groups\nGroups are simple mechanisms to categorize Proxy Endpoints for organizational convenience. Use of Groups is optional.\n \n## Hosts\nHosts are how you access the APIs and Proxy Endpoints that you have defined. They are basically domain names. At least one host entry has to exist for an API to be publicly available. When you create a new API in your nanoscale.io account, we will add a new host entry for you by default. It will look something like: <word>-<word>-<number>.nanoscaleapi.io.\n \n## Proxy Endpoints\nProxy Endpoints are the individual calls, methods, or routes that comprise an API. Proxy Endpoints belong to one Environment and, optionally, one Group. A Proxy Endpoint will contain one or many proxy components that may implement custom logic in JavaScript or pull data from a Remote Endpoint.\n\n## Proxy Components\nProxy Components are the bits and pieces that make up a Proxy Endpoint. You have JS Logic components, single remote endpoint call components, and multi Remote Endpoint call components. You define and stack these building blocks to implement the behavior of your Proxy Endpoint. These are also referred to as \"Components\" at the top-level with an API. In this case they are just simple proxy components that can be defined once and reused between different Proxy Endpoints.\n \n## Remote Endpoints\nRemote endpoints are external calls that can be invoked by a Proxy Endpoint. Nanoscale.io enables quick declarative configuration of Remote Endpoints and allows for quick calls programmatically defined by JavaScript. Once you define a Remote Endpoint, it can be used within multiple Proxy Endpoints.  \n\n## Shared Components\nShared Components allow developers to build reusable components within an API, which can be used across multiple Proxy endpoints. Similar to Proxy Endpoints you can define JS Logic call, single Remote Endpoint call or a multi Remote Endpoint call. \n\n## Shared Libraries\nShared Libraries enable the developer to define centralized JavaScript functions that can be used across Proxy Endpoints.\n\n## Logs\nLogs give you insight into how users are hitting your APIs and what they are doing with them. They will also give you insight into errors in your JavaScript and Remote Endpoint configurations. Nanoscale.io will automatically log information through a request lifecycle, however, you also have the ability to log arbitrary information yourself in your JavaScript logic. Logs can be access in the Admin Dashboard either statically or via streaming.\n\n## API Documentation\nAPI Documentation will automatically be generated for each of your APIs and Proxy Endpoints. Swagger JSON meta data will be available for each API and is used in the Admin Dashboard to render Swagger Docs.\n \n## Session\nA Session is an object that contains session information. Nanoscale.io supports both a cookie store and a server side store to persist sessions. This can be configured by environment. You may programmatically manipulate an API user's session in your Proxy Endpoint JS logic.\n \n## Workflow\nEach Proxy Endpoint in an API responds to requests based on how its Workflow is configured. A Workflow consists of a sequence of components, each of which can be used to (1) call a Remote Endpoint via a Single Call Component, (2) call multiple Remote Endpoints in parallel via a Multi-Call Component, or (3) run JavaScript in a Logic Component. A Workflow might consist of some JavaScript logic that returns a specific response depending on the value of a parameter or header in the incoming request. Or, a Workflow might invoke a request to a Remote Endpoint, and convert the XML returned by the Remote Endpoint to a JSON response. See [API Creation Workflow](doc:api-creation-workflow) for more information on how Proxy Endpoint Workflows and Components are used.\n\n## Collections\nEvery account has access to Collections under the 'Manage' section of nanoscale.io. Collections are used to store any object data. A collection can have any name you want and can be used to store an JSON objects. These collections can be defined and accessed in the Dashboard by any Proxy Endpoint by using the Local Store remote endpoints.","excerpt":"","slug":"terminology","type":"basic","title":"Terminology"}
## API An API represents a collection of related calls. Each call is a Proxy Endpoint that consists of either JavaScript logic only, or proxies the request to one or more Remote Endpoints. ## Environments Environments enable you to maintain multiple sets of session settings and variables. For example, you may have a “development” environment that contains settings and variables which are different from your “test” and “production” environments. Environment variables can be referred to within JavaScript code in the Proxy Endpoint. At least one Environment has to exist, and a “Development” Environment is created by default. ## Groups Groups are simple mechanisms to categorize Proxy Endpoints for organizational convenience. Use of Groups is optional. ## Hosts Hosts are how you access the APIs and Proxy Endpoints that you have defined. They are basically domain names. At least one host entry has to exist for an API to be publicly available. When you create a new API in your nanoscale.io account, we will add a new host entry for you by default. It will look something like: <word>-<word>-<number>.nanoscaleapi.io. ## Proxy Endpoints Proxy Endpoints are the individual calls, methods, or routes that comprise an API. Proxy Endpoints belong to one Environment and, optionally, one Group. A Proxy Endpoint will contain one or many proxy components that may implement custom logic in JavaScript or pull data from a Remote Endpoint. ## Proxy Components Proxy Components are the bits and pieces that make up a Proxy Endpoint. You have JS Logic components, single remote endpoint call components, and multi Remote Endpoint call components. You define and stack these building blocks to implement the behavior of your Proxy Endpoint. These are also referred to as "Components" at the top-level with an API. In this case they are just simple proxy components that can be defined once and reused between different Proxy Endpoints. ## Remote Endpoints Remote endpoints are external calls that can be invoked by a Proxy Endpoint. Nanoscale.io enables quick declarative configuration of Remote Endpoints and allows for quick calls programmatically defined by JavaScript. Once you define a Remote Endpoint, it can be used within multiple Proxy Endpoints. ## Shared Components Shared Components allow developers to build reusable components within an API, which can be used across multiple Proxy endpoints. Similar to Proxy Endpoints you can define JS Logic call, single Remote Endpoint call or a multi Remote Endpoint call. ## Shared Libraries Shared Libraries enable the developer to define centralized JavaScript functions that can be used across Proxy Endpoints. ## Logs Logs give you insight into how users are hitting your APIs and what they are doing with them. They will also give you insight into errors in your JavaScript and Remote Endpoint configurations. Nanoscale.io will automatically log information through a request lifecycle, however, you also have the ability to log arbitrary information yourself in your JavaScript logic. Logs can be access in the Admin Dashboard either statically or via streaming. ## API Documentation API Documentation will automatically be generated for each of your APIs and Proxy Endpoints. Swagger JSON meta data will be available for each API and is used in the Admin Dashboard to render Swagger Docs. ## Session A Session is an object that contains session information. Nanoscale.io supports both a cookie store and a server side store to persist sessions. This can be configured by environment. You may programmatically manipulate an API user's session in your Proxy Endpoint JS logic. ## Workflow Each Proxy Endpoint in an API responds to requests based on how its Workflow is configured. A Workflow consists of a sequence of components, each of which can be used to (1) call a Remote Endpoint via a Single Call Component, (2) call multiple Remote Endpoints in parallel via a Multi-Call Component, or (3) run JavaScript in a Logic Component. A Workflow might consist of some JavaScript logic that returns a specific response depending on the value of a parameter or header in the incoming request. Or, a Workflow might invoke a request to a Remote Endpoint, and convert the XML returned by the Remote Endpoint to a JSON response. See [API Creation Workflow](doc:api-creation-workflow) for more information on how Proxy Endpoint Workflows and Components are used. ## Collections Every account has access to Collections under the 'Manage' section of nanoscale.io. Collections are used to store any object data. A collection can have any name you want and can be used to store an JSON objects. These collections can be defined and accessed in the Dashboard by any Proxy Endpoint by using the Local Store remote endpoints.