Not possible to extend northbound API

[MichelSc]

I use version 2.16 of the iotagent-node-lib libary.

I want to extend the norhtbound API with for instance a method POST /iot/links.

It would come handy to have a handler call back allowing us to add custom http methods to northboundServer.router.

The callback would be called somewhere in function NorthboundServer.start().

An alternative would be to use the methods POST or PUT with the property internal_attributes, but this is not possible because of issue #1083

[fgalan]

An alternative would be to use the methods POST or PUT with the property internal_attributes, but this is not possible because of issue #1083

Could you elaborate on this? How would you use internal_attributes to support the feature you mention about extending the northbound API?

[MichelSc]

My need is to tell the agent there is a link of type T between device a and device b.

One solution could be to extend the api of the north bound port with a new method POST /iot/links with as body something like [ { source: "a", target: "b", type: "T"} ].

But I did not find a hook to extend the northbound api (this issue).

So as work around, I use the internal_attributes feature. Instead of a POST /iot/links that I cannot implement (this issue), I use POST /iot/devices with in the body:

            "internal_attributes":  {
                "sources" : [ 
                    {
                        "device_id" :  "source002",
                        "linktype_id": "link001"
                    }      
                ]    

And then I implement my logic in a provisioning handler.

Problems with this work around:

• I can create (OK) but I cannot update (NOK): this is issue #1083
• at the time the provision handler is called, the device is not yet added and I need to consider all the devices at hand (the new one and the devices already provisioned); so this makes my life a bit harder
• I would prefer a dedicated method for a specific function

[fgalan]

The northbound API has a defined semantic and any potential extension should be taken into account with care. Is device linking a general feature that the whole community of IOTA users would need? Or it is only specific of your use case?

[MichelSc]

About device linking:

• in the context of this issue, it is an example why I need to extend the api with specific directives
• this issue does not demand to extend the api for device linking, but simply to be able to add new directives or methods.

If it is not possible to extend the northbound API, then I will have to implement the API on another port

• this would be a 'westbound API'
• unfortunate that
  • some of the management API is via north port, and another part via west port
  • that we would need 2 ports for 1 function
  • that we would have to implement another port, while this is already done by the framework
• this would limit the usefulness of the iotagentlib framework
  • or rather, the ability to extend the api would increase the usefulness :-)

[mapedraza]

This proposal goes somewhat against the philosophy of the library. The objective is to standardize the common functions and that they enable the agents development in a fast and uniform way. Adding new arbitrary endpoint covering custom needs to modify and alter the operation of the library would make the agents much more heterogeneous and would complicates the management of these, opening the possibility of "infinite" modifications.

Have you tried to solve the problem in the upper layer of your application?

[MichelSc]

Again the issue does not require to add new end points, but to have to possibility to add new ones. This issue requires a hook to get the control at northbound server startup with the northboundServer.router to be able to do a router.post() like you do in the loadContextRoutes methods.

We can solve this problem at application level. This is not difficult. But unfortunate because

• then we would have to implement another port, while this is already done by the framework
• some of the management API is via north port, and another part via the new ad-hoc implemented port
• then we would need 2 ports for 1 function
• these extra end points will not be executed in the requestDomain like the existing northbound end points

Such extension would in our eyes greatly enhance the usefulness of the iotagent-node-lib framework.