cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to community-mailer@ptc.com. Learn more.

Difference between API and SDK

VacuumDecay
5-Regular Member

Difference between API and SDK

Hi, 

 

I would like to know if the API works the same as SDK, or the SDK have more capabilities like the "AlwaysOn" agent? 

1 ACCEPTED SOLUTION

Accepted Solutions

Ah, ok, now it's clear.

I suggest (and I'll explain below why) the following courses:

1. https://developer.thingworx.com/en/resources/guides/choosing-connectivity-method

2. https://developer.thingworx.com/en/resources/guides/thingworx-java-sdk-tutorial

3. https://developer.thingworx.com/en/resources/guides/sdk-reference-guide

4. https://developer.thingworx.com/en/resources/guides/use-edge-microserver-ems-connect-thingworx

 

The main reason you need to take these courses is because the enterprise nature of the applications we see out there really makes the patterns the Edge SDKs use be mandatory in those scenarios. When you look at the Edge SDKs you might be tempted to say: well, I can do that with REST, since it uses that platform service, etc, but trust me, if you go with the REST approach, that won't work at scale. It's fine for a couple tens of devices, and even in this case, it depends on the property update rate...

Ah, and one other thing: if you are going to work with edge devices, never, ever put software agents that do not have an update capability in your edge devices. Even if it's not required in the project/s, work with your customer, and make him understand that that's a very big security gap - you don't want to be left exposed out there to the next security issue and require people to go physically to update the agents.

View solution in original post

5 REPLIES 5

Hi @VacuumDecay,

I assume that the API you refer is the REST API? And the SDK you refer to is the Edge SDK? Asking because there's a server SDK, that allow you to write Java server-side extensions.

In the case assumed before, the methods available in the REST API are exactly the ones you can access via the EDGE SDK, but the EDGE SDK has a different way to work with the platform (ot just calling APIs) and many more OOTB functionalities suited for edge devices (Remote Properties, Remote Services, Remote Events, File Transfer, Duty Cycle settings).

However, can you please describe in detail the use-case you are looking to implement to be able to suggest the best way going forward?

We have seen in the past very precise questions similar to this one, which gave birth to incorrect implementations (albeit relatively functional), and I'd like to make sure you choose the best path

VacuumDecay
5-Regular Member
(To:VladimirRosu)

Hi @VladimirRosu , 

 

Thanks for your prompt reply, I am referring to this link

 

If they have the same capability, I will prefer to wrap the REST API with my own functions, since I am not familiar enough with any of the available SDKs.

That link points mainly to the full ThingWorx server REST API.

You still did not answer my question, so I can't advise if you would choose the correct path

I understand it's easy to choose what you know, but especially in the case of new technologies it's not always the best path, hence my question

VacuumDecay
5-Regular Member
(To:VladimirRosu)

Hi @VladimirRosu ,

 

I am only planning for my learning path, to decide if I need to also learn the SDKs.

 

If the REST API is suffice, I can try to program my own wrapper around the API. 

 

Thanks! 

Ah, ok, now it's clear.

I suggest (and I'll explain below why) the following courses:

1. https://developer.thingworx.com/en/resources/guides/choosing-connectivity-method

2. https://developer.thingworx.com/en/resources/guides/thingworx-java-sdk-tutorial

3. https://developer.thingworx.com/en/resources/guides/sdk-reference-guide

4. https://developer.thingworx.com/en/resources/guides/use-edge-microserver-ems-connect-thingworx

 

The main reason you need to take these courses is because the enterprise nature of the applications we see out there really makes the patterns the Edge SDKs use be mandatory in those scenarios. When you look at the Edge SDKs you might be tempted to say: well, I can do that with REST, since it uses that platform service, etc, but trust me, if you go with the REST approach, that won't work at scale. It's fine for a couple tens of devices, and even in this case, it depends on the property update rate...

Ah, and one other thing: if you are going to work with edge devices, never, ever put software agents that do not have an update capability in your edge devices. Even if it's not required in the project/s, work with your customer, and make him understand that that's a very big security gap - you don't want to be left exposed out there to the next security issue and require people to go physically to update the agents.