Web Services

think your routing in the unnecessary and screwing it up

Managed to sort it all out; posts, requests all of it. Working nicely now. Starting to look like a proper service now. I tell you what, flip, this was a bit of a mission.

It was the routing. Thanks Spacerat.

public static void Register(HttpConfiguration config)
{
config.Routes.MapHttpRoute(
name: "DefaultApi",
routeTemplate: "api/{controller}/{id}",
defaults: new { id = RouteParameter.Optional }
);
 
SO what do I do with the XML from the service? It's pretty useless to me at the moment. How do I use it?

I did the whole xsd utility/http://xmltocsharp.azurewebsites.net/ route. Gave me this gibberish class. No idea what to do with it.

Parse it, then whip it into the shape you need.

So draft a schema, and manipulate the data until it adheres strictly to that schema, write some tests for type and validity while you're there. No use in having prestine data once and it breaks 3 months from now because the api changed on their side.

Figure out timing, how often does it update, what happens further down the line with new data (auto crud basically)

Et voila, once you have everything lined up, you can start with the business logic, and actually making the data useful.
 
Well....it works at least. Not perfect but it works.

Screenshot-2.jpg

Sol, with regards to this... You might want to look at an amalgamation of these fields on the frontend.

What I see when I look at this...

1. He's going to build a dashboard, and he's going to need a way to display and manipulate those results (and print them to paper)

2. The user is dumb, no matter how smart. So autocomplete on those fields would make life a lot easier.

Give the user an escape hatch, a reset and try again, clearing the current state.

It is a fine balance between, shipping data to the frontend en mass and losing the user due to load / processing time.

Ship a thin veneer of data and query the rest from your api as required.

When the time comes, and you are ready, and a frontend needs to be built. Post your ideas here, if you need help.

Good luck! These are rough but charted waters.
 
Last edited:
That above was just more for my sake really so I could visualize the calls to the service.

It is a fine balance between how much data to send back from the api exactly. Thanks John_Phoenix I'm plowing ahead with the service itself. I won't make the move to Core just yet, at the moment still working with asp.net

Watching some youtube tutorials and fixing it up, modifying as I go along, separation of layers etc, it's slowly coming together. I'll pop back here soon when comes time for the UI.
 
If you can afford $29 a month, register on Pluralsight. There are excellent courses on MVC etc by Scott K Allen from MSoft
 
If you can afford $29 a month, register on Pluralsight. There are excellent courses on MVC etc by Scott K Allen from MSoft

Scott Allen, know him yes. Will definitely check that out.

Finding myself venturing more and more into MVC territory by default with learning web api and finding it a nice and refreshing change from WinForms.
 
Anyone here use Swagger? I've heard you can generate your api methods with Swagger. Is it useful?
 
Anyone here use Swagger? I've heard you can generate your api methods with Swagger. Is it useful?

Yeah we use swagger. It's useful in that you don't need to document what your endpoint takes as a request and gives as a response. Swagger does this for you. So you just send a link to whomever is consuming you service.
 
Yeah we use swagger. It's useful in that you don't need to document what your endpoint takes as a request and gives as a response. Swagger does this for you. So you just send a link to whomever is consuming you service.

Thanks schuits that makes it a bit clearer. I'll probably have some more questions as the week rolls on. Needing to do a Swagger crash course.
 
There is also a nuget package called Microsoft.AspNet.WebApi.HelpPage that will generate documentation for web api controllers.
 
Top
Sign up to the MyBroadband newsletter
X