ASP.NET WEBAPI Internal/External Usage

Question

Introduction

• We are in the beggining of the development of a new web client for our current web application.
• And we will take the chance to build a REST WebApi to access our assets (to be consumed by third parties, and also our new web client)
• We're considering OAuth, Service Quotes, Application permisions, etc for the WebAPI
• We want to "eat our own dogfood", so the new webclient must use the webapi...
• Important: The webApi and the webClient will be hosted in the same server

Questions

A simple use case would be "Get the menu page links"

1. For the web client which of these 2 approach would you choose?

   • a) Generate an html with a Js webApiCall inside it to be called from client web browser to get the available menu links for the user. = (2 round trips: 1 for the html/aspx + 1 for the api call MenuGetAvailableItems )
   • b) Generate an html with the data menu links already populated (webApi MenuGetAvailableItems consumed internally in server side) = (1 round trip for html/aspx + an API internal call..)

2. If you choose option 1B, Is it possible to avoid the http overhead by consuming the api from the same server and mantain the security, Quotes, etc? I mean, can we use some WCF mechanism or other to communicate this 2 webs instead of making an http call to localhost...?

Thanks for your comments

Answer 1

Q 1

regarding option a - I would avoid calling Web API from the web page, you will start to run into problems with CORS. Also, what if you want to use authentication to access the Web API service, how are you going to send a user name and password from the web page!

regarding option b - you certainly can consume the web api service from inside your web app.

Q 2

I don't understand your what you are asking.

---

If your primary purpose for building a web service is to allow a third party to interact with you, you are going to want build just the services that need to be exposed.

In general, "eating your own dogfood" might not be the best reason to use Web API where standard calls to the database would be more appropriate. You going to have two applications running, when all you really needed was a data tier in the web app.

It sounds like you are going to end up with a sprawling Web API app that will need new services every time you want to add something to your site.