Creating an API

Hi,

I'm looking for your advice for the best way to do something rather than actually being stuck on a particular problem.

We have many clients that run our own Windows based software, which uses a localised MS SQL Server Database for it's storage.

I am looking to write a central API web service of some kind that I can use to allow website (and perhaps other third-party) developers to access (on an authorise only basis) their customer's data.

The user name and password should decide, which SQL database to use when obtaining the data. This is so one developer does not end up with someone else's data!

I'm really wondering which ways you would go about doing this.

Some point to consider are:

Interoperability
Although, I write code in VB.NET, I need to know that the API can be used by both MS based developers (ASP/MVC etc.) and others like php developers etc. At the same time, if the developer does have a leaning towards MS based languages, it would make sense that they can have intellisense for my properties and methods where possible.

Large Data Streaming
Some of the customers we have, upload many thousands of products to their websites. Granted these are not new products going up each day, but the developer may need to get an up-to-date list of all the products, so that he can compare them with what he's got in his website already. The solution I put in place would need to cater for this without tying up the server's resources so much that other's requests are crippled or sat waiting.

Scalability
I would likely start the API by offering only basic information  - for example SKU code, Description, Sell Price, Cost Price etc. but in time, it would without doubt grow to include further fields. I need the method I put in place to make this easy to do (for me) whilst not breaking anything existing developers are out there using.

I have had a play with ASP MVC Identity 2.0 and also WCF. I am using Visual Studio 2013.

I just wanted to get some feedback from you guys as to which way you would do it (so please don't just post links to sites containing hundreds of pages of reading) before I do a load of work down the wrong path.

Thanks in advance.
LVL 1
JedNebulaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

käµfm³d 👽Commented:
Although, I write code in VB.NET, I need to know that the API can be used by both MS based developers (ASP/MVC etc.) and others like php developers etc.
Then a web service is certainly a good approach to take. While you can achieve such in a WCF service, WCF is bulky, as well as very complex. Using a RESTful approach, especially that offered by Web API (1 & 2), tends to be much easier to craft and manage.

At the same time, if the developer does have a leaning towards MS based languages, it would make sense that they can have intellisense for my properties and methods where possible.
You would only get that with WCF, and simply because clients would most likely use "Add Service Reference" to automagically create the proxy class for them. With Web API, there are no tools yet to build such proxy classes, so if you wanted to do the same, then you'd have to create a library that wraps your service, and then distribute that.

Large Data Streaming
You'll have to quantify just how large "large" is, but generally speaking, large data streams across the Web, not to be confused with the Internet, aren't the most reliable. It can be done, but usually the user experience tends to suffer. You might consider offering a way for the data to be broken up (a.k.a. paging), so that you can server up smaller data sets one at a time. In this way, your user experience is better.

In terms of payload, pretty much any environment can handle either XML or JSON content. JSON is much smaller, of course, and I believe most of the web world leans towards this. I've recently been looking at Google's Protocol Buffers format. It's ridiculously small in its payload, but it is still a new technology, so there is no guarantee that a library exists in a client's programming langauge of choice. They do offer, though, examples in C++, Java, and Python, so you've at least got those covered. There is a .NET library that exposes this functionality to you as well; it's just not maintained by Google. There are some limitations on when to use PB, though.

Scalability
You can certainly scale if you go the web service route, and if you structure it correctly, then you can do so without breaking existing functionality. You do have to be concerned with versioning when it comes to potentially breaking changes.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
JedNebulaAuthor Commented:
Thank you ever so much kaufmed - a great reply.

Would you mind just expanding on your last sentence:

You do have to be concerned with versioning when it comes to potentially breaking changes.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
WCF

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.