I understand Web API. I understand websites, how they call a web API and all the good stuff. My question is, how do you control the user view in the website consuming the API, based on the API permissions. The goal would be to not have the view in the website if the user is not authorized to preform such action. Not just do a trick and hide it the HTML (Tech-savey user can see html code for actions/data forms they shouldn't).Simplified Scenario: User has access to API to create other users, but not delete. They can technically send the delete verb to the URI, but they would get access denied. The goal would be for the HTML website to not show the delete option in the first place, as they cannot preform the action anyway. As well as no way of knowing via the website HTML/JS to see where the delte option is/how it works (Of course the delete view shows to users with that permission set)Idea's:Have API support sending the HTML code for views on the site based off permissions. -Not a big fan of this as I feel it sorta breaks the idea of the API. What if I need to do something similar on a mobile app?Use server side code as intermediary to call the API and build the view. -Im not sure about this because I feel it will require a redundant amount of work, but may be the best option.I am using c# .net for this, if that matters. Preferably strictly HTML JS for the website, but don't believe thats possible unless sending HTML from the API.
Consuming Web API in website with role based views
c#;javascript;api;asp.net;html
The goal would be to not have the view in the website if the user is  not authorized to preform such action. Not just do a trick and hide it  the HTML (Tech-savey user can see html code for actions/data forms  they shouldn't).I agree with you. That would be the ideal case to me too. However, I consider this to be implementation details. There's nothing wrong in hidding the HTML code, as soon as the API implements authorization and authentication.A tech-savey doesn't need to look into the code. For example, he/she can track the  browser connections and try for each URI of the API, different HTTP methods. Basically, he/she can bypass the client and attack the API from any other application (curl, Postman, java client, etc...)how do you control the user view in the website consuming the API,  based on the API permissionsAnyways, if the API stick with REST, there should be possible for us to achieve what we want. What we need first is to know what actions are we  allowed to perform. This should be  possible with the method OPTIONS. 1AuthorizedOPTIONS /rest/api/product HTTP/1.1Host: example.netAuthentication: ...HTTP/1.1 200 OK Allow: HEAD,GET,DELETE,OPTIONSUnauthorizedOPTIONS /rest/api/product HTTP/1.1Host: example.net    HTTP/1.1 401 UnauthorizedThis is easier to say than done. It might result in many more calls to the API than the initially expected.A way to solve the previous problem with OPTIONS could be implementing HATEOAS. In other words, we could make the API more descriptive.Implementing HATEOAS the API response doesn't only provides resource representations. It also provides links to more resources. Links can be as descriptive as we deem it appropriated. For example, look at the PayPal API model.The view would populate its controls according with the links. No link, no control (button, form, etc.)Regarding your ideas, I agreed too. I would not mix API and views. Every client has its own concerns and these concerns -IMO- should be addressed independently. The more agnostic is the API to these problems, the better.As well as no way of knowing via the website HTML/JS to see where the  delte option is/how it works (Of course the delete view shows to users  with that permission set)I will assume that we already solved the problem with the HTML block. According with your conocerns, the user still could look at the JS code. Yes, and we can obfuscate the code too.On the other hand, if we don't want users bulding their own clients, we can (should) provide them one. For example, like Google does.1: According with the Allowed methods, we decide what to do. Just remember that Javascript can hide DOM elements by altering styles, but it can also add/remove elements dynamically too.