Getting Started with Profound API

A valid API must follow these rules:

  • API file name must end with .api.json – example: customers.api.json (not case sensitive)

  • API file must be within a Workspace or within a directory that is included on the pathlist

Using Low-code steps and Plugins to build the API Logic: 

  • See more information on Low-Code Steps and Plugins

  • You can use the Database tab and generate a Table API.  Notice the different plugins and how they are put together to build a routine.

  • There are many shipped plugins; you can build your own as well.

  • The Low-code designer allows for:

    • Add new steps by clicking on the "Add Step...", choose the type of plugin, and answer its questions.

    • And you can move around steps or brackets with drag and drop.

Document your APIs:

  • Both for yourself and for the consumer.

  • On the General Information panel, you can provide some level of information such as category, tag, summary and description and output description.

  • On the Input and Output Parameter panels, you can provide a description and example to any parameter.

  • This information is bundled up into an OpenAPI specification document.

API are ready to be used in real time.  Any time an API file is saved within the API Designer, they are immediately ready to be consumed. This is because the API framework uses Hot module reloading.

  • If you upload an API file, the framework will start serving it immediately

  • If you move an API file around in the directory tree, the framework will adjust accordingly

  • If you delete an API file or an API, the framework will stop serving that API in real time, as well

Using RESTful API Design concepts.

  • Following these guidelines will help make your APIs simple to consume and expressive.

REST vs Soap

  • Profound API primarily emphasizes RESTful API publishing, but starting from version 6.2.0, it also includes support for building and publishing SOAP APIs. This guide offers insights into the distinctions between REST and SOAP.

  • The examples in the Getting Started section focus on REST, however there is a section dedicated to SOAP located here.

Run manual Test over your APIs

  • You never know what the consumer of this API might be calling the API with.  It's good for your API to return with a error reason and way to correct instead of a generic error.

Run performance tests on your APIs

  • It is nice to have good performing APIs. Running specific test and looking for slow response rates, large payload sizes or long handle times can show potential bottlenecks within your business logic.