I have a scenario where my ASP.NET WEB API returns 2 different models depending upon the request object. I am using swagger UI (through swashbuckle) to document my ASP.NET WEB API and currently is unable to find a way to document these 2 models against 1 ASP.NET WEB API action.
I have tried googling but was not fruitful. any help will be appreciated.
The OpenAPI (formerly known as Swagger) specification version 2 does not have any way of describing two different models for the same operation. With the new OpenAPI V3 you can use a schema with the oneOf attribute to describe multiple possible response shapes.
However, there isn't much tooling available yet for V3.
Related
I have 2 APIs need to be integrated so the data will be pulled from one API using the GET method and post to the other API using the POST method.
Both APIs use the same authentication mechanism and accept JSON objects.
What is the best way to achieve this goal with less effort and best results using .net core?
Can a custom middleware help in this case?
When I started development of my current project I had no knowledge or prior experience of web development, ASP.Net (Core), C#, JS and so on.
With a lot of reading, excercising and testing I now have an ASP.Net Core 2.2 web application with multi-tenancy based on the database-per-tenant strategy hosted on Azure with Azure SQL as backend.
I have a solution with 2 projects:
the MVC web application that also has the .Net Core Identity from which I use the individual user accounts stored in ASPNet... tables (I did implement my custom UI, mainly so I could use the Localization middleware already used throughout the application)
a data layer that contains the db context's, the data models and the repository
Now I need at add an API.
The sole purpose of the API is cleary defined: give customers(tenants) the possibility to import and export data, most likely connected to other customer's application(s). This API will not be used by the UI. The API will not be hit with thousands of queries per second. It will be part of a business solution with 50 to 200 customers who will perform occassional import/export actions.
I have already implemented Identity and the authentication for the API should be done against the users setup in Identity but with a different authentication mechanism.
I have done a fair bit of searching and reading and found many tutorials/blogs on how to create a WebAPI with .Net Core but they all start from a new project and never go much more into depth. The once that really go in-depth are too complex for me ...
I have 3 questions unanswered at the moment although I know that there's probably more than 1 good answer to each of the questions but I think these are the likes of questions that many in my position, beyond the newbie/beginner but not yet a seasoned veteran, have and are searching for so I hope this post helps not just me but many others as well.
Question 1 - Architecture, where to create the API (project)?
There are 3 possibilities:
1 Add APIControllers to the MVC application (organize API-related classes in separate folders)
Benefits
quick and easy, everything else is already in place
deploys with the solution
Concerns
as it is part of the solution it becomes very monolithic, less flexible
Questions
can I implement a second authentication/authorization mechanism next to the implemented individual user accounts? (more detailed in the second question which is all about security)
2 Add a WebAPI project to the solution
Benefits
better separation but can still use/reference the resources of the other projects
probably gives benefits for scaling and tuning?
Questions
can I implement a second authentication/authorization mechanism next to the implemented individual user accounts leveraging the Identity of the MVC project? (more detailed in the second question which is all about security)
is this project separately published to Azure (or any cloud provider for that matter) using the www.example.com/api path (virtual directory) or is the solution published a whole?
3 Create a separate solution with the WebAPI project and include the data layer project
Benefits
full separation although sharing the use of the data layer project
completely independent with regards to deployment, scalability etc.
Concerns
maybe adds a layer of unnecessary complexity (the API will not handle thousands of requests per second)
Everything that is already configured/setup in the MVC project and that is required will need to be redone
Questions
can I include the data layer project in the solution (it is then part of 2 solutions) or should I reference it as a dll?
Question 2 - how to implement Authentication/Authorization that resides side-by-side with the Identity individual user account?
This is related only to the first 2 options of the architecture as in the third option the project would be on it's own.
The basic question is how to setup more than one authentication mechanism, one for UI users and another for API access.
First there is the choice of Authentication, most of tutorials blogs talk about JWT and Auth (OAuth?). I am not asking what the "best" solution is but which solution would be "preferred" by B2B customers who are the only ones that will use the API.
I am not sure how to redirect to the right authentication: when a request is sent to an API controller method with the Authorize attribute and the user hasn't been authenticated yet it needs to reply with an error.
Currently if a method with the Authorize attribute is executed by an unauthenticated user the user is redirected to the login page as configured in startup.cs:
public void ConfigureServices(IServiceCollection services)
{
...
services.PostConfigure<CookieAuthenticationOptions>(IdentityConstants.ApplicationScheme,
opt => {
opt.LoginPath = "/User/Login";
...
Do I need to configure this with something like the example I found below:
app.UseWhen(x => (x.Request.Path.StartsWithSegment("/api", StringComparison.OrdinalIgnoreCase)),
builder =>
{
builder.UseMiddleware<AuthenticationMiddleware>();
});
or is this configured in a different way?
In the case of creating the API as a separate project should I use the "Multiple startup projects" option? I guess this means that I need to create the whole startup.cs again?
Question 3 - if I want to offer my customers a REST API and an OData API, can I handle this through a single API or do I need to develop a second to support OData?
I know it is lengthy but I'm sure that others are looking for similar information and I'd appreciate any input.
Thanks
I created a Web API with .Net Core.
I currently have the form from the .cshtml page posting through to a normal MVC controller and then using the HTTP Post method to post to the Web API endpoint.
Is it better to post directly from the form on the .cshtml to the WebApi endpoint?
I'm relatively new so not sure which is better.
Imho the current approach is correct: you post some data to a controller inside your application and then do stuff with this data (in this case sending them back to a Web API).
Why is correct? Because you can do all sort of checks inside the controller before sending any data to the Web API (like data validation, transformations, composition etc...). Also, I'm not sure if you can post directly to a Web API using Blazor methods for posts. To do that I think you have to write the form using plain HTML and than detect the submit event using Javascript, where you finally post the form data to the Web API. But again, I think the current approach is good (if not optimal)
it's not a bad solution by any means but if your API is publicly accessible (not just from your web project with the mvc controllers) I would suggest posting directly to the API.
Posting directly to the API reduces roundtrips. And also the validation and everything should be handled by the API.
Use Web APIs when you want to deal with data or HTTP status codes only, i.e. not expecting HTML to be returned. Typical use cases from a web perspective are doing any asynchronous communication through Javascript (native JS, Vue, Angular, React, JQuery, etc....)
If you expect HTML to be returned, use MVC or whatever view framework you want to use. In this case it is perfectly fine to call other APIs from the MVC controller.
We want to expose (through an API) big data collections that are a combination of flat file/binary files and xml files. Currently we do this with WCF Data Services (OData), and tranfer this data using a custom Untyped Data Provider as described in this tutorial (past 4): http://msdn.microsoft.com/en-us/data/gg191846
Performance is bad though and customization is hard, so we are thinking of 'upgrading' to ASP.NET Web API (2). Daniel Roth from the Web API team has given an interesting talk at TechEd2013 on the differences between WCF Data Services and Web API (see it here: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-B209) and at 1h06m he mentions briefly that 'Web API doesnt support untyped data yet, but it's coming'. I'm a little confused as to what this means for us. Does this mean that ASP.NET Web API is a no-go for us no matter what, or that we can move to Web API, but will (probably) still need a custom data provider? Any insight would be appreciated!
Looks like this update came at the right time: http://www.asp.net/visual-studio/overview/2013/release-notes
Type-less support
You can now build OData services without needing to define CLR types for your entity types. Instead, your OData controllers can take or return instances of IEdmObject, which are the OData formatters serialize/deserialize.
I need to access the Enterprise WSDL using the Salesforce API in my Java app. Can anybody help with this?
Salesforce WSDLs are only available in the Salesforce UI, not through the API. You can get them at:
Setup | Develop | API
If you find that need to get the Enterprise WSDL at runtime because your application needs to work with different sets of objects and fields, you should probably be using the Partner WSDL instead. It will allow you to get all the object and field descriptions at runtime and make dynamic API calls. There a little more work upfront, but results in a more flexible and resilient application. When the objects and fields change in the future, your application will continue to work without re-consuming the WSDL.
The WSDL is not available through the Salesforce API (to my knowledge). However, it is available through a REST call if you have the right information. First, you need a session token, generated through either an OAuth handshake or a username/password+security token handshake. You also need the name of the Apex class from which you generated the WSDL. With those two things, you can perform a GET. See the following pseudo-code for the requisite GET structure.
GET https://<SANDBOX_INSTANCE_URL>/services/wsdl/class/<APEX_WSDL_CLASS_NAME>?isdtp=p1
Headers:
'Cookie' : 'sid=<SESSION_TOKEN>'
EDIT:
I verified that this works with both Enterprise/Partner WSDLs and WSDLs generated from custom Apex classes.
You can use the following generic URLs for these WSDLs, as of v41.0:
Partner: https://<SANDBOX_INSTANCE_URL>/soap/wsdl.jsp
Apex: https://<SANDBOX_INSTANCE_URL>/services/wsdl/apex
Metadata: https://<SANDBOX_INSTANCE_URL>/services/wsdl/metadata
Tooling: https://<SANDBOX_INSTANCE_URL>/services/wsdl/tooling
Tooling (Enums): https://<SANDBOX_INSTANCE_URL>/services/wsdl/tooling?enumStyle=ALL_STRONG