Web Applications for DeepSee REST Services and JavaScript APIs

According to the documentation (2016.1) we can use either a system defined web application (/api/deepsee) or create a custom web application for handling requests. What are some reasons to use one rather than the other?

  • 0
  • 0
  • 211
  • 0
  • 4

Answers

If you're okay with /api/deepsee as it is - use it.

If, however, you want to change some settings (auth methods for one), then it's better to define your own application, since your changes may be lost during system update.

Some  clients may simply not want to expose the /csp... to mask thay this is based on ISC technology.

Some customers may have existing Web apps they are migrating to ISC technology and they may want to mimic their existing URL naming conventions.

Here is the case, when you probably will need at least two web apps for DeepSee REST API.

Consider you want  some data to be accessed with authorisation and you provide this access with /webapp1 which is set up with authorisation by password.

And maybe you want some data to be accessible for everyone - you can do it with /webapp2  with option for UnknownUser.

When working with embedding DeepSee into your applications, you may wish to centralize all of the REST calls both to your application and DeepSee.  Since the DeepSee REST API extends from %CSP.REST, you could either choose to call it directly from your REST service that you develop using %CSP.REST (using a service map), or make a service that is in the same logical path as your existing REST service so that things look the same to the browser.