Limit REST calls

[iguerra]

I would give to customers a free and limited number of REST calls per month, and only passing trough a specific thing (basically I need only POST) 

I have done this using that thing with some services that are called with REST POST requests ... but is there a way to limit or block all the other native REST access to objects ?

If there isn't a possible limitation, can a customer cause problems making too many REST calls per second (even in unintentional) ?

I have PTC hosted thingworx 8.5.3 instance.

[slangley]

Hi @iguerra.

Can you provide more information regarding your concerns?  What is the use case?

ThingWorx doesn't limit the number or type of REST calls.  You would need to control what type of access the customer has within the Security of your application.

In regard to your question about "making too many REST calls per second," keep in mind that system resources would have to be monitored to ensure the system is capable of handling the traffic.  There are many factors here, such as bandwidth, JVM memory, etc. that may have to be reviewed if you are having issues.

Please provide more information so we can ensure we are answering your question appropriately.

Regards.

--Sharon

[iguerra]

Hello @slangley 

I have two main focus, considering I need to give REST access to our customers.

All is related to security and system stability.
Note that I think to a wrong use of REST by our customer... more like a curious user trying to see what is possible to do with REST (moreover if he knows that the system is based on thingworx!)

1. limit access to REST calls to only few things (a sort of rest gateway).
   I know all security for REST (as soos as the "composer access" by the end-user) should be made with objects visibility and runtime/designtime permissions, and we made a lot of analysis and fixes to do that, but it is still possible to list objects and do a lot with REST calls, this is an "open gate" (and big IMHO) that could expose unwanted data.
2. I would give to customers a free REST plan with a number of calls per months, and another as a paid option with higher number. I made this (using POST / service calls) ... but it is not useful if anyone can bypass and browse all the other objects with REST (point 1) ...

About performance, we have PTC hosted TWX instances so I don't know the effect of too many REST calls per second. I would just know how to consider this (point 2 was also to set a limit on the number of calls, as many web services do).

[Constantine · Accepted solution]

Hello @iguerra,

If you want to do it right -- you'd have to use some external API Gateway, such as Azure API Management, WSO2 API Manager, etc -- there are dozens of commercial and open source solutions.

It would sit in front of your ThingWorx instance and handle security, request throttling, service subscriptions, documentation, API marketplace, API versioning, data transformations (e.g. GET --> POST), etc. You can control this gateway from your ThingWorx, for example by creating user or customer accounts corresponding to your ThingWorx users.

Unfortunately those services are not free (although WSO2 is Open Source, you still need to host it somewhere), but if you plan to scale your API business, then eventually you will have to use something like that. ThingWorx doesn't provide any of that functionality out of the box -- any user who can display a list of things in a mashup can cause a denial-of-service just by executing this query in an asynchronous loop.

Regards,
Constantine

[iguerra]

Hi @Constantine 

ok, however the thingworx webserver remains "open" to rest calls if someone tries to do requests directly, right ?

[Constantine]

Not necessarily, it really depends on how you want it.

For example, you can have some ThingWorx user accounts for "web users", who should have access to mashups (those will be able to bring the system down anytime, if they want to). At the same time you can have "API-only" user accounts, which will never login via the browser and their credentials will only be exposed to that API Gateway via appkeys, then the Gateway will "protect" your ThingWorx from abuse.

If you want to protect your ThingWorx just by limiting the rate of requests (a simpler approach, but still very efficient), you can do it by hiding it behind some rate-limiting reverse proxy. Here's an example: https://www.nginx.com/blog/rate-limiting-nginx/

[slangley]

Hi @iguerra.

If one of the previous responses answered your question, please mark the appropriate one as the Accepted Solution for the benefit of others with the same question.

Regards.

--Sharon