http://localhost:8081/api/kos/handlesCore Concepts
URL Namespaces
Introduction
This article discusses the core concept of URL namespaces, which deals with how URLs are managed in KOS.
Overview
The webserver in KOS supports both content and endpoints:
-
Content comes from the virtual file system (VFS)
-
Endpoints come from API controller (@ApiController) classes
Content includes things like HTML web pages (static and dynamic), support files like JavaScript, CSS, image, video, and other types. A browser opens and uses these components.
Endpoints are HTTP/REST interfaces. They use the HTTP GET/POST/PUT/DELETE methods, and can accept input data and return output data. KOS comes with many built-in endpoints, and the software developer is free to add their own custom endpoints.
Namespacing
KOS controls the URL namespace by managing where the VFS content is added and where the API namespace endpoints are added.
|
Note
All endpoints start with |
Internal KOS
All internal KOS controllers are located at /api/kos, which puts them in the kos namespace. KOS doesn’t have any content, therefore there is no VFS equivalent.
System App
Within KOS, the system app is special. The system app defines a context that is shared by all other apps, a classloader parent for all other apps, and it has a dedicated URL namespace. The system app VFS is rooted at /system. This means that any content you mount has a /system prefix. Similarly, all endpoints reside at /api/system.
Synopsis
The following table shows the content and endpoint prefixes used by KOS.
| Component | Content | Endpoints |
|---|---|---|
KOS internal |
none |
|
special "system" app |
|
|
regular app |
|
|
|
Namespacing
To reiterate, there are three types of components related to URL namespacing:
And there are two types of URLs:
|
Examples
In the following examples, let’s assume we’re running a KOS application inside the Studio simulator, and that the HTTP port is set to 8081.
Internal
Endpoints
To see a list of all handles in the KOS system, hit the following endpoint. Note the URL pieces:
-
/api: prefix indicating an HTTP endpoint -
/kos: indicates internal KOS -
/handles: the API controller’s base address -
<missing> : missing piece, meaning that the controller has a default method
Content
There is no internal KOS content.
System
Endpoints
To hit a custom ping endpoint in a system app, use the following URL. Note the URL pieces:
-
/api: prefix indicating an HTTP endpoint -
/system: indicates the special system app -
/mycontroller: the API controller’s base address -
/ping: the API controller’s endpoint method
http://localhost:8081/api/system/mycontroller/pingContent
VFS KAB file mounted at /ncui in the system app:
http://localhost:8081/system/ncuiApp
Endpoints
To hit a custom ping endpoint in a regular app, use the following URL. Note the URL pieces:
-
/api: prefix indicating an HTTP endpoint -
/myapp: the app ID -
/mycontroller: the API controller’s base address -
/ping: the API controller’s endpoint method
http://localhost:8081/api/myapp/mycontroller/pingContent
VFS KAB file mounted at /something in the myapp app:
http://localhost:8081/app/myapp/somethingSummary
In this article, we looked at how KOS URL namespaces are allocated.
To get some hands on experience with these concepts, take a look at the Hello World tutorial.
On this page
Java Development
Seamlessly transition from Legacy+ systems to Freestyle microdosing and advanced distributed dispense systems.
UI Development
Using KOS SDKs, integrating Consumer and Non-consumer facing UIs becomes seamless, giving you less hassle and more time to create.
Video Library
Meet some of our development team, as they lead you through the tools, features, and tips and tricks of various KOS tools.
Resources
Familiarize yourself with KOS terminology, our reference materials, and explore additional resources that complement your KOS journey.
Copyright © 2024 TCCC. All rights reserved.
