Web service - new
Clients of BioAware that have the BioloMICS web version are able to request the activation of a webservice for their own database.
To see the full process of the Admin part and the UI (User Interface), see Web service Admin and UI.
For instructions on how to get the authorization token, see How to get the authorization token for the webservice.
Introduction to APIs and Their Role
An API (Application Programming Interface) is a set of rules and protocols that enable different software applications to communicate.
Acting as middleware, it allows one application to access the data or functionality of another without needing to know its internal technology.
For example, BioloMICS is built with the .NET framework, but any external application—regardless of its programming language—can interact with it through its API.
Data Formats and the RESTful Approach
APIs typically use a standard data format such as JSON (JavaScript Object Notation), which is both human-readable and easy for machines to process.
The BioloMICS API is a RESTful API, following the REST architectural style with defined rules for building web services.
It offers a consistent interface for interacting with resources, ensuring all requests are processed in a standardized way.
Endpoints
An API is made up of various endpoints, each representing a unique address where a specific function can be performed.
Available endpoints are: GET, PUT, PATCH, PUT and DEL.
HTTP Protocol, and the Request–Response Model
The API enpoints are accessed via the HTTP protocol (in this case, HTTPS for security).
HTTP APIs follow a request–response model, where a client sends a request (including an HTTP method (e.g. GET) with the URL, headers, and response body (also called payload) in JSON format) and the server returns a response.
The responses include an HTTP status code. Those codes are grouped into categories:
-
1xx: Informational
-
100 Continue – The request has started; the client can continue sending the rest of it.
-
2xx: Success
-
200 OK – The request succeeded.
-
201 Created – A new resource was successfully created (often after POST).
-
202 Accepted – The request is accepted for processing but not yet completed.
-
204 No Content – The request succeeded, but there’s no response body.
-
3xx: Redirection
-
301 Moved Permanently – The resource has a new permanent URL.
-
302 Found – The resource is temporarily at a different URL.
-
304 Not Modified – The cached version is still valid; no need to resend data.
-
4xx: Client errors
-
400 Bad Request – The request is invalid or malformed.
-
401 Unauthorized – Authentication is required or failed.
-
403 Forbidden – The server understood but refuses to fulfill the request.
-
404 Not Found – The resource does not exist.
-
409 Conflict – The request conflicts with the current server state.
-
422 Unprocessable Entity – The request is valid but contains semantic errors.
-
5xx: Server errors
-
500 Internal Server Error – A generic error on the server.
-
502 Bad Gateway – The server got an invalid response from an upstream server.
-
503 Service Unavailable – The server is down or overloaded.
-
504 Gateway Timeout – The upstream server didn’t respond in time.
Documentation UI
API documentation explains how to interact with the API, listing its available endpoints and operations.
It’s generated from the OpenAPI specification (the YAML file created from the API’s admin section).
This file contains:
-
all the endpoints (GET etc.) with their descriptions,
-
all the parameters and the response available for each endpoint.
-
Security part which described how to perform an authentication on the API in order to grant access to different users.
It can be downloaded for use in tools like Postman to create test endpoints automatically, or to generate code for developers to work with the API.