search

ni / systemlink-OpenAPI-documents

MIT License
16 stars 22 forks source link

Swagger document for WebApp Service #69

Closed tschmittni closed 4 years ago

tschmittni commented 4 years ago

Added Swagger document for /niapp routes of the WebApp Service.

This is an update to the old PR: https://github.com/ni/systemlink-OpenAPI-documents/pull/47

tschmittni commented 4 years ago

I recently found out that this is not the API exposed by SystemLink Cloud and that only /api/webapps/ routes are public for Cloud

/api/webapps is not a public API. This is just an internal route which is forwarded to the https://api.systemlinkcloud.com/niapp/v1 routes.

In order to actually be able to leverage shared code between Server and Cloud in our clients, we are planning on creating a wrapper exposing the /api/webapps/ routes.

You don't need to create another wrapper. The /api/webapps are internal cloud routes and not meant to be stable or used by external clients. They are also not following any SystemLink naming standards. They are just a wrapper around the public APIs.

We should not create another wrapper on SystemLink server to leverage shared code. Instead of creating two separate wrappers providing the same abstraction, we should just use the existing common /niapp/v1 routes in both cases, Cloud and Server.

========

This could be really just a simple as this: https://github.com/ni-kismet/helium-webserver/pull/1171 And we move the dashboard builder over to these routes and remove the /api/webapps routes.

mure commented 4 years ago

@tschmittni Thanks for clarifying this for us. One of the benefits of the /api/webapps wrapper in cloud is a simplified duplicate route. The /niapp/v1 webapps service only provides a route to duplicate content, meaning that our UIs have to make multiple requests just to duplicate a document. Would it make sense for us to add another route to the webapps service similar to the /api/webapps one?

tschmittni commented 4 years ago

The /niapp/v1 webapps service only provides a route to duplicate content, meaning that our UIs have to make multiple requests just to duplicate a document. Would it make sense for us to add another route to the webapps service similar to the /api/webapps one?

Sure, if you need it just go ahead.