|
RESTSharp is out as my REST client, because it 'throws" if the objects your're sending have interface properties. It says "cannot create an instance of an interface". You're not supposed to. If the property has a value, that value isn't an interface, or down until you get a serialise object.
Yet I used quotes around "throws", because it give ResponseStatus: Error, yet it has sent back perfectly serialised JSON, so if I only comment out the response status check, and just blindly try and deserialize, it should probably work.
Half the google hits for the problem are elephanting idiots that suggest changing your model structure to not use interfaces, just for that one little transport. Elephant, people are stupid!
|
|
|
|
|
If your property is an interface how does it know what concrete class to set as the value?
public class Cat : IAnimal
{
}
public class Dog : IAnimal
{
}
public IAnimal MyAnimal {get;set;}
How does it populate MyAnimal? With Cat? With Dog?
|
|
|
|
|
It doesn't have to serialise class declarations, only already instantiated objects, and then we know what is implementing the interface. The build in clients handle this fine, and for a few more lines of code, but one less package, I'm going with them.
|
|
|
|
|
I've never really seen the appeal of these libraries anyway, I always use the built-in classes, it's not that much code to call a REST service out of the box. There seems to be a type of developer that thinks nothing can be done without a NuGet package! (that goes double for JSON serialisation)
|
|
|
|
|
I thought maybe it would give me something nice like a standard request, with all correct headers etc. and a well implemented async/await. Hahahahahaha.
|
|
|
|
|
Two questions:
- Why not use .NET's WebRequest, and possibly NewtonsoftJson if you need Json serialization/deserialization?
- I haven't looked at RestSharp's code, but I can't imagine it's that complicated (but knowing how some of these projects are written, I'm probably totally wrong) but it seems like it might be easy enough to tweak for what you need?
Marc
|
|
|
|
|
Marc Clifton wrote: Why not use .NET's WebRequest
Because that's so last year? HttpClient[^] is what all the cool kids are using these days. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: Because that's so last year?
I resemble that remark. 
An interesting comparison[^] - quick read.
I guess because I have a little get\post class that still uses WebRequest and NewtonsoftJson of the serialization, I've never looked further.
Marc
|
|
|
|
|
I hear all over the nets that WebRequest is obsolete.<a href="https://blogs.msdn.microsoft.com/henrikn/2012/02/16/httpclient-is-here/">HttpClient</a>[<a href="https://blogs.msdn.microsoft.com/henrikn/2012/02/16/httpclient-is-here/" target="_blank" title="New Window">^</a>], the new kid on the block is very easy to use, except without the luxury of RESTSharps typed requests, which did all that auto-magically.
So now I'm using HttpClient, and NewtonSoft, which is always one of the first packages I add. With web clients I cannot abide PascalCased names on JavaScript's side of the park. Using HttpClient, for a POST to fetch data, it's only four lines of code before serialising. I can easily wrap that in a helpful method so I don't even know how I get my object, I just get it.
|
|
|
|
|
Brady Kelly wrote: With web clients I cannot abide PascalCased names on JavaScript's side of the park.
I know what you mean. Though it I also dislike the "foo_bar" naming convention that I have to deal with at work (Python/Django backend), so happily there's JsonProperty to decorate the class names.
I'll have to look at RestSharp though, even barring your complaint about it. Though, perusing the code, I can't really tell if all those classes are necessary -- it's hard to wrap one's head around the architecture if the architectural considerations are not described. Gotta love open source.
Marc
|
|
|
|
|
I've just got a WPF app that access a central DB through a Web API, and token based auth. It's about 24 hours hard work, but I have my afternoon naps and TV at night, so in all it's about a week. I have nothing else to do, having just submitted an simple, but non-trivial, file search app as a technical assessment for a job opening in Dublin. That would be a dream come true.
|
|
|
|
|
And since when are elephants dumb? Because Republicans?
|
|
|
|
|
|
Here we go, some things need to remain no matter what happens (that's not a hint!):
Fever, or immanent? It doesn't stop. (7)
|
|
|
|
|
U. G. Leander wrote: that's not a hint!
But it is! A hint for the Soapbox 
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: A hint for the Soapbox
Well, it is seven letters...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
FOREVER?
Anagram of FEVER OR, but I don't get the "immanent" part ...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
FOREVER is correct, well done!
'immanent' was meant to imply that 'OR' is inside 'FEVER': F-OR-EVER
|
|
|
|
|
It looks like some tech writer was determined to keep his job for as long as possible -- the installation guide for Symantec Endpoint Protection runs to 1156 pages.
Since we're on the topic of gambling, lately, I'll bet that I could cut it down to ten.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You can read it in less than 10 minutes - on YouTube...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I can cut it down to one word, or actually contraction.
"Don't"
|
|
|
|
|
Probably works as well as McAfee Endpoint Encryption, which we have here at work. Lovely bit of kit, as our U.K. friends say. If your computer fails and you need to move your hard drive elsewhere to read back the data, you are irretrievably and utterly elephanted. The drive is encrypted such that the data is only usable in the original hardware it is installed in.
Software Zen: delete this;
|
|
|
|
|
Endpoint Protection != Endpoint Encryption
|
|
|
|
|
Toe-may-toe, toe-mah-toe, let's call the whole thing off. The purpose of most IT departments is to cram so much sh!t on their users' PC's such that they are rendered unusable without constant action by the aforementioned IT department, thereby justifying their existence.
Software Zen: delete this;
|
|
|
|
|
Remember: Not everyone in a corporate environment is as computer savvy as the devs.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
