Room for RhysW and motosubatsu

RhysW

13:18

So i'll give a little background, just so you have some context as to what i'm on about

motosubatsu

hello sir!

fire away..

RhysW

We already have an existing website, and all business logic has been done in the controllers.

We are whitelabelling our product, so I have started the joys of moving all the business logic to methods in an API

For example a user comes to our site and gets a 'quote' for what we might sell to them and the price it would be

motosubatsu

makes sense, pretty common scenario where you would want an API

RhysW

The step I am deliberating about is how to handle 'failures', for example if i call the CreateQuote method but don't pass it some required parameters, or if there is a conflict between bits of information (e.g cant have both A and B, so the quote is invalid)

im unsure if the api should be responding 'nicely' with a response that has Success false and an error message property and an enum with the failure reason

or if i should be less friendly and throw exceptions etc

or if there is a third option i hadn't even considered

motosubatsu

really as much as possible I would subscribe to the notion that an API should "fail" as politely as possible as much as it can

you always should work from the assumption that the person/application that is calling it is a) untrustworthy and b) an idiot

and therefore you should expect to get badly formed requests and it should take them in it's stride and report back helpfully without revealing underlying technical info if it can be avoided

RhysW

13:27

yeah i can agree with that. thats the same reasons i had when considering what i was doing. I started doing it that way but ended up hesitant because im creating a lot of enums to report back varying failure reasons.

Like i've got a CreateQuoteFailureReasons enum that lists all the reasons creating a quote could fail (shared between the 4 different 'types' of quotes you can have, differing products')
And another for CreateUserFailureReasons which lists all the reasons creating a user might fail

motosubatsu

how many values are we talking about for these?

RhysW

less than 10 per enum

as im making them quite generic

motosubatsu

that's pretty manageable

RhysW

so the CreateQuoteFailureReason enum has a value for RequiredFieldNotProvided. and that is returned for any of the three required fields, and another property has a friendlier message

motosubatsu

that sounds about right to me.. generic-but-helpful values for the common cases that will be obvious to the caller when they encounter them and then some more specific ones for the more involved scenarios

I'm assuming this is a RESTful API?

so webAPI2 or similar?

RhysW

13:36

its a bit confusingly set up, and might technically only be an api in name

we have a controller in the 'main' site. Calls to that controller forward the data to our business logic managers.

Our whitelabel product will have a nuget package installed, and calls to that nuget package just forward it to the 'main' site, and then returns the result the site returns

motosubatsu

@RhysW and that controller is a regular MVC one I'm guessing?

RhysW

yeah, with some added security of course

motosubatsu

I'm guessing you have the actions on the controller return some sort of JSON-formatted response object that the calling whitelabel instance then deserializes and takes appropriate steps with?

RhysW

the controller returns its objects to the nuget package that calls it, which does the deserialization and hands a nice .NET object to the whitelabel that made the call

motosubatsu

makes sense.. it's a bit convoluted but essentially it isn't far off how a "conventional" API would flow

RhysW

13:47

yeah it's a little crazy, but the nuget package approach is one implemented (on much smaller scale) in some of our other smaller projects, so sticking to it for consistency

out of curiosity what would your set up be instead?

having the whitelabel call the 'main site' controllers directly?

motosubatsu

The conventional paradigm the controller would be a webapi2 controller that would accept requests directly from the client (presumably the whitelabel in your case), the nuget package wouldn't be required

adding the nuget package in isn't "bad" exactly..but it depends on what your goals are. If you want to encourage ease of integration for third parties looking to use the services then a straight RESTful API is a well traveled path that keeps things flexible

RhysW

@motosubatsu as far as i am informed this 'API' is strictly for internal use only. Just a far easier way for us to set up the whitelabel products than our previous implementation

motosubatsu

@RhysW that being the case then using the nuget approach (and keeping it consistent with how things are done elsewhere in the organisation) is sensible

RhysW

for the WebApi2 approach i've just looked into it (haven't used it before) and i found this: docs.microsoft.com/en-us/aspnet/web-api/overview/…

and i see its returning IHttpActionResult s, how does that tie together with providing information about why a call to the api might have failed?

motosubatsu

@RhysW that's the puppy

RhysW

13:53

don't mean to be a barrage of questions! is that all then handled through the status code returned, or customer made responses that implement the interface?

motosubatsu

don't focus too much on that IHttpActionResult - a RESTful api can essentially return ANY object that can be serialised

RhysW

ah gotcha, so ours is sort of similar to that approach, just with the deserialization put into a seperate section, where usually it would be directly within the calling application?

motosubatsu

exactly

in your case, assuming you aren't under huge time pressure on it

I would actually implement it as a webapi, have the nuget package consume that api

and if in the future you ever need to open that service up to clients that aren't in the expected path of using the nuget package

you can tell them it will take a week to change it and put your feet up and read SE

RhysW

@motosubatsu when you say 'consumes' i'm not sure how that differs from what our nuget package already does

(im pretty much entirely self taught, so there's probably a lot of straightforward stuff i've not come across)

motosubatsu

@RhysW it isn't really.. in that example the nuget package would pretty much do the exact same thing it does now

there isn't even really much in the way of changes at the other end either.. in a simplistic sense WebAPI2 is essentially normal ASP.NET MVC but without the "V"

RhysW

13:59

ok that's good to know.

motosubatsu

calling it an "API" just makes us backend coders feel all important :)

RhysW

Thanks for all this, I hugely appreciate the help!

motosubatsu

not a problem..happy to help :)

RhysW

It's always nice to check in every so often to know i'm not inventing new wheels. If I can ever return the favour in the future just let me know!

motosubatsu

sometimes you just need to bounce things around a bit with someone who speaks the same language as it were :)

and thanks, I appreciate it. believe me I get stuck on things often enough!

thinking on your situation, I'd be very tempted to create a "response message" object type for each of your main functionality areas

and have that response object definition contain the fields for both successful and unsuccessful calls

RhysW

14:05

@motosubatsu funnily enough this is exactly what i've done to the letter!

motosubatsu

hahah.. great minds think alike and all that :)

RhysW

nice, I feel more confident about my choice now, I better start cracking on with it then. Then I get to the joys of documentation much quicker...

motosubatsu

cool.. give me a shout if you need to bounce ideas around again at any point :)

RhysW

I'll keep it in mind, thanks again!

Transcript for

Room for RhysW and motosubatsu