If I want REST endpoints for PI data, which one is better to use, PI Web API or custom ASP.Net API using AF SDK?
If you just want a RESTful web service that retrieves PI data, my suggestion is to use PI Web API. The advantage is that it is a product used by many people and therefore very well tested. This applies not only from the performance standpoint but also from the security perspective.
A custom ASP.NET Web API project with PI AF SDK is a good option if you:
Hope it helps!
My colleague Marcos Vainer Loeff has given a very good answer. The only thing I would add on top of his reply is that PI Web API is well integrated into other OSIsoft product offerings such as PI Vision.
I am echoing the answer by Marcos but adding my own emphasis of remarks that stood out to me:
BEGIN QUOTE FROM MARCOS:
If you need specific functions that are not supported by PI Web API, then it is worth to develop custom Web API. (Like tag's annotation or AF versionning etc...)
PI Web API's good point is that OSIsoft will continue developing/ enhancing it.
See the load map and the next version PI Web API 2017 contains performance improvement.
That is why I recommend to use PI Web API. Finally I believe PI Web API use AFSDK. So if you develop it by AFSDK and if you use the same method, then the performance should be the same. (Please allow me that currently I don't know that what PI Web API team changed the code for performance improvement for PI Web API 2017. Maybe bulk call/ pararell etc?)
You can use both PI Web API and a custom ASP.NET Web API with AF SDK to create those custom methods if needed!
My concern is also the performance of PI Web API as I would be hitting this API from a custom build web/mobile application and there would be around 2500 users using the application with transactions happening every second.
Maybe PI Web API team can comment about the performance. Daphne Ng
I think one of the advantages to using the PI Web API is it's ability to handle multiple connections. I'm not an expert in this area, but my understanding is the AF SDK is single threaded out of the box, so if you have a large number of connections there could be issues. The PI Web API actually uses the AF SDK, but has a layer to handle many concurrent connections. As far as performance, you might want to look at what is would take to set up some kind of load balancer if you are going to have a large user base and how much work that would involve with either approach.
If scalability and the number of concurrent users is a concern, perhaps using a network load balancer with multiple PI Web API servers could help.
Yeah, as Michael Tippett mentioned, multiple machines are good option.
As a performance perspective, PI Web API 2017 should show double or triple faster than the previous version.
At first, I recommend to test PI Web API 2017 after it will be released.
I hope our product is enough performance for your company.
+1 to Marcos's response.
You may also want to weight up what percentage of the required functionality PI WebAPI will do for you. If it's a good portion then go with that and build something custom to run in parallel or on top of it. As the PI Web API grows, it will be less effort to transition functionality over down the track (depending on your or your companies philosophy of how much custom code you're happy to maintain).
Also, if there are any calcs required, maybe take that back up a level and use Analytics Service to perform some of those functions.
Performance is important and the PI Web API was built with that as one of its key features.
The below post might be useful in addition to Marcos Vainer Loeff comments :
PI Web API Architectural Question
Retrieving data ...