Failing at API dev

Why would you run a front end against a webapi vs just adding the code to the front end itself?
Unless with front end you mean an external application consuming the services?
To improve the end-user experience however you define that.
1. You have a shared backend but an optimised UI so customised not responsive. Desktop for power users and mobile for light users, mobile users won’t be using keyboard shortcuts etc.
2. You want to deliver a familiar UI across platforms implementing something like React.
3. You don’t need server side rendered HTML, you rather have lower latency responses so you cache at edge nodes.


@_kabal_ im on dot net 5 web api. It works lekker, ive added JWT and call limiting etc.
I don't use the built-in swagger though, i want to customize my swagger file per client, so i just create rhem in the editor.
If it’s the same API, then take a look at the Filtering option in Swashbuckle.


Also something i have not found a solution for is having lots of APIs and now i need to update one. I cannot do it independently, the whole project must be deployed. I can probably split the project but each dot net 5 project in iis needs a new application pool. Haven't read up on that yet.
If you can split the project then maybe look at a service mesh or API gateway approach, if you’re forced to use only IIS then Application Request Routing is an option.
 
Look at Ocelot gateway as a orchestrattor for multiple api/microservices. You can even present a combined swagger which loads the other swagger docs as sub docs.



As to why would you want a website to talk to a api vs code, centralized and reusable logic, especially in enterprise. Api's are the intelligence and everything else are just front ends :web, native apps, services, b2b api. Then you can dive into things like queues, topics etc as well for distributed processing or data sharing.

Depends on use cases, always consider fit for purpose.
 
Last edited:
Look at Ocelot gateway as a orchestrattor for multiple api/microservices. You can even present a combined swagger which loads the other swagger docs as sub docs.



As to why would you want a website to talk to a api vs code, centralized and reusable logic, especially in enterprise. Api's are the intelligence and everything else are just front ends :web, native apps, services, b2b api. Then you can dive into things like queues, topics etc as well for distributed processing or data sharing.

Depends on use cases, always consider fit for purpose.
Business logic needs to be re-usable by being in the service layer (web api). The idea is to not repeat any logic that can be behind the api. Keep front end apps as this as possible. Also look at this for managing your api: https://azure.microsoft.com/en-us/services/api-management/, and for orchestration I would use Microflow.
 
I like to separate my backend from the controller due to SRP. IMO the controller‘s function is only
to marshall / route the HTTP request to the entry point and perform auth. The controller then uses DI‘ed services to do whatever it needs to. Back-end services should not care about the middleware protocol be it HTTP, TCP socket or whatever.

I like to return an object from my back-end service that indicates success or fail and then also error descriptions. The error description is *in the user’s language*. The language translation is done in the back end. Also in the case of a successful request you may want to pass back a notification or warning to the user. This is also included in the service’s response. The controller’s job then is to translate the service response to a sensible HTTP response. After all, that is what the controller is there for; marshalling HTTP requests and responses.

The HTTP spec makes provision for detailed additional info in any response. I posted a link to it elsewhere

I'm essentially trying to get a standardized wrapper going on the mvc front end. Something that captures both the header response, codes etc and also captures the results of say Employees. If I can get that going I wont bother with fancy api response objects I will just gooi the results back straight. This is what I'm trying to get at. I don't always explain what I want so well!
 
I'm essentially trying to get a standardized wrapper going on the mvc front end. Something that captures both the header response, codes etc and also captures the results of say Employees. If I can get that going I wont bother with fancy api response objects I will just gooi the results back straight. This is what I'm trying to get at. I don't always explain what I want so well!
You and @Thor should really get together for a coding weekend or something.
 
I'm essentially trying to get a standardized wrapper going on the mvc front end. Something that captures both the header response, codes etc and also captures the results of say Employees. If I can get that going I wont bother with fancy api response objects I will just gooi the results back straight. This is what I'm trying to get at. I don't always explain what I want so well!
Then it’s all good. For your own private API build it how you want till it breaks because it will, then you can apply that knowledge to APIs for 3rd parties like implementing paging at the beginning.

Like I said previously these are vast topics that sometimes require understanding a ton of things, HTTP might be agnostic but JSON isn’t, you can look at an API and figure out what the backend was implemented in because things like naming conventions carry through.

Your code might not break but the SDK might or the OS or something else, only a few know the pain of status 100 codes.
 
First I want to send response objects say in a wrapper encompassed in an http response. Get told bad idea. Then I want to rather send straight data back and not worry about wrappers. Get told bad idea. This must be what going mad feels like.
 
First I want to send response objects say in a wrapper encompassed in an http response. Get told bad idea. Then I want to rather send straight data back and not worry about wrappers. Get told bad idea. This must be what going mad feels like.
Easy fix, cater for both responses.
 
First I want to send response objects say in a wrapper encompassed in an http response. Get told bad idea. Then I want to rather send straight data back and not worry about wrappers. Get told bad idea. This must be what going mad feels like.

What you could do is look at examples of APIs out there (pick a fun one like https://rickandmortyapi.com/) and code a small app against it. This will give you an idea of how the api contracts are implemented, why it is done, what works and what doesn't.

...and then you go code your own.
 
Last edited:
You can also include your XML comments in Swagger for better documentation.

Thanks I'll take a look at that. I have the default swagger implementation running, barring one thing, requiring authentication authorization via login and then bearer token input, apart from that it's pretty bland. Need to look at this now and improve on it.
 
Thanks I'll take a look at that. I have the default swagger implementation running, barring one thing, requiring authentication authorization via login and then bearer token input, apart from that it's pretty bland. Need to look at this now and improve on it.
Stripe is always the go to example for good documentation, you’re not limited in UI either. Sometimes I find ReDoc better to use.

MS Docs has an entire section dedicated on how to write technical documentation.
 
And it's monday morning!
Now I get to deal with json responses where A can be an object or an array depending on what went wrong ( and for fun all the text is in arrays).

"errors" : {
"A" : ["Some error text"]
}

"errors" : {
"A" : {
"b" : ["Some error text"],
"c" : ["Some error text"],
}
}
 
Top
Sign up to the MyBroadband newsletter
X