Bizcoder - Latest Comments

Re: RESTfest was a blast

Sub Systems — Sat, 18 Sep 2021 02:25:04 -0000

Nice post

Re: Optimizing for the Speed of Light

Patrice Krakow — Mon, 17 May 2021 06:13:52 -0000

This is one of the best piece of advice I have found to discuss the "API aggregation pattern" (or whatever the name you give it). I am using it a lot, way too much indeed, as you could have expected that more than two years later the message would be mainstream... but, it's not.

And it sounds that it is not only in my neighborhood, as I have just found out the famous sentence "This chattiness between a client and a backend can adversely impact the performance and scale of the application." in the documentation of Azure :'( see https://docs.microsoft.com/...

Your colleagues should read your blog posts, even if "no one is a prophet in his own country" ;-)
@Darrel, that has been a while (Feb 18 2019), please continue to write good stuff!

Re: RPC vs REST is not in the URL

Maxim Kammerer — Mon, 01 Jun 2020 19:02:11 -0000

Thanks for the article and discussion, very informative! But the topic of your discussion was still somewhat "philosophical", wasn't it? I mean whether an action is implemented e.g. with a POST on some resource or as a separate RPC endpoint is ultimately a matter of taste since it has no direct impact on the traits of the architecture.
Isn't HATEOAS the main difference between the two approaches since an RPC endpoint could fulfill all the remaining REST constraints?

This question might a bit silly because I'm a newbie trying to wrap my head around the two concepts :-)

Cheers

Re: Bizcoder - Recent Posts

Steve Stacel — Mon, 11 May 2020 16:49:54 -0000

Hello, I want to connect to our Kronos time provider to get the a report from their API. I am using HTTPClient. I have a username, password, company id and an Api-Key. I cannot figure out how t also need Accept and Content-Type in the request header to login to the website. Once successful I token will be returned. I need to pass a token into the report so that it is authehticated and I can retrieve the data. How do I add the credentials and the Api-Key to gain access to the system and get the token. Does some one have some sample code they can send me. There is so much confusing data on the net I cannot figure this out.

Re: Posting raw JSON to Web API

Douglas — Wed, 18 Sep 2019 07:54:16 -0000

It helped me a lot. Thanks

Re: Posting raw JSON to Web API

Xavier John — Wed, 24 Apr 2019 21:12:26 -0000

JToken strategy is working but
[HttpPost] public async Task<httpresponsemessage> Process(HttpRequestMessage request)
is not working. The Content on request is null.

Re: Don't Design A Query String You Will One Day Regret

hexvolt — Wed, 30 Jan 2019 13:05:30 -0000

Very useful, thanks

Re: Constructing URLs the easy way

Daniel Meza — Thu, 13 Dec 2018 10:54:33 -0000

It is a awesome work here, I'm work in a multi platform MVVM framework to and I wish use this to accomplish url navigation, I thing that defining templates in views can add much flexibility, soo tell me if I'm wrong but I can use the UriTemplateTable to store routes and them when a request come check if the url match any route and then proceed to navigate based on that match.

Re: RPC vs REST is not in the URL

Kenneth Marshall — Mon, 06 Aug 2018 13:30:00 -0000

Looking at both of your arguments made me understand the difference RPC and REST. Good constructive arguments... started off shaky with some attitude but it was entertaining...lol

Re: Using Nuget to give Web API that Add Service Reference experience

Matt Knowles — Fri, 27 Jul 2018 13:03:43 -0000

I found this proposal helpful, but I'm still not sure how to deal with the fact that the model objects on the server will have behavior in them that is not suitable for the client applications to use directly. Have you found a good way to deal with that?

I understand that I could create a "ContactData" class, and have that shared between client and server, with the server having a "Contact" wrapper that encapsulates the "ContactData" and adds behavior. But this significantly complicates the simplicity of being able to serialize the server objects directly using the TypeNameHandling of Newtonsoft.Json.

Re: Posting raw JSON to Web API

Anurag singh — Mon, 13 Nov 2017 11:43:09 -0000

Brilliant!
Amazing!
My Savior!!

Re: XSLT is easy, even for transforming JSON!

yamahito — Fri, 07 Jul 2017 15:08:35 -0000

There's more than one way to skin that cat. The article is suggesting something from JSON.net. You can also use something like the rex parser generator to parse the JSON and output it as XML (it can even generate a parser in XSLT).

The best way, IMO, is to use XSLT 3, which supports parsing JSON as part of the standard (see https://www.w3.org/TR/xslt-... ). There are free XSLT engines available that implement this, my favourite is Saxon: https://sourceforge.net/pro...

Re: XSLT is easy, even for transforming JSON!

yamahito — Fri, 07 Jul 2017 15:01:11 -0000

Arthur, consider using Saxon. There is a javascript implementation for compiled XSLT transforms in the browser. You'd still have to pay for one developer license (potentially as part of an IDE like oxygenxml), but there is no charge for server implementation.

XSLT 1.0 might be dying. But many would argue that it is a good thing, it is an obsolete technology wrt XSLT 2.0 and 3 (recently announced as a new W3C standard)

Re: Posting raw JSON to Web API

Steve Culshaw — Wed, 08 Feb 2017 12:19:55 -0000

Excellent post ... made my life a lot easier

Re: Posting raw JSON to Web API

Programmer — Wed, 11 Jan 2017 09:23:06 -0000

Hi, thanks for this simple explanation it has helped me a lot.

Re: Returning raw JSON content from ASP.NET Web API

Navin — Mon, 28 Nov 2016 13:07:48 -0000

Really great article. Thanks for sharing!

Re: Don't Design A Query String You Will One Day Regret

Sascha Gottfried — Thu, 24 Nov 2016 10:53:16 -0000

I am actually reading your webapi book and want to present it to my team mates. I already mentioned it shortly and told them I wondered that there is not a single reference to OData in the whole book. While reading the post I realized there are good reasons why the authors promote the recommendations found in the book as well as in your post. Thanks for sharing these insights.

Great post, Darell
Great book anyway

Re: Posting raw JSON to Web API

David De Sloovere — Thu, 10 Nov 2016 06:54:17 -0000

Thanks. JToken was what I needed.

Re: Posting raw JSON to Web API

TalynOne — Fri, 07 Oct 2016 02:21:28 -0000

Thank you! This came in very handy today. This is very useful for PATCH json payloads.

Re: RPC vs REST is not in the URL

Darrel Miller — Wed, 21 Sep 2016 18:16:25 -0000

Ok, I think I'm getting a better understanding of our respective perspectives.
HTTP has a very limited set of methods. To make up for that, I think we need to be creative with resources to overcome those limitations. Being strict about resources being "entity like" is something I find extremely limiting in designing APIs. I am definitely in the camp where a resource can be anything. My application doesn't have "resources" that I expose via HTTP. I create resources to achieve the goals my clients applications are trying to achieve. Resources can be literally anything that is useful to me.
And therefore, I have no issues with modelling actions as resources, and I don't believe there are any negative system effects. And I would never call that RPC, because I don't think those are the characteristics of an RPC system, but obviously we disagree there.
You are calling something RPC, that I consider completely RESTful. You make the point in your article that RPC and REST can be used side by side, so I guess our only true point of contention is what we call stuff. Which is not worth getting stressed over. I care far more how systems, perform and evolve.
Hopefully, I haven't annoyed you too much with my zeal.

Re: RPC vs REST is not in the URL

philsturgeon — Wed, 21 Sep 2016 17:56:36 -0000

My reply was short because I was letting the StackOverflow replies do the talking. I agreed with them, so paraphrasing or rewording would have been pointless. Sorry if you felt snubbed.

> There is no REST constraint that says a resource must respond to all methods.

Didn't say that. :)

> There is also no reason that a GET method could not return statistics on recently started trips.

There is definitely a school of people out there who consider " Any information that can be named can be a resource" as "you can name literally anything with some daft name so I guess literally anything can be a resource". That's a bit of a stretch when it comes to inventing new resources just so your arbitrary actions can be a bit RESTy.

That's pretty much what I was talking about when I mentioned bending things to make it feel like it fits.

What I'm saying is: having a random endpoint with arbitrary fields to do an action is RPC-style. If that action is crowbarred into your app, left as it is, and is just a "I take payload and arguments please" then it's RPC.

You _could_ REST it up a little by inventing a whole new resource concept for the sake of it, but that's an extra step on the example provided, and potentially a step beyond what most people would take. Even then, it seems like a bit of a stretch, and something done only for the sake of making it be REST.

Do you see the distinction I'm making there?

> However, to try and say that actions are not RESTful is basically saying the HTML based web isn't RESTful. The HTTP POST method quite naturally handles unsafe requests that may or may not create resources.

That's literally not at all what I'm saying. I'm not sure how you got to that.

Re: RPC vs REST is not in the URL

Darrel Miller — Wed, 21 Sep 2016 17:43:30 -0000

I appreciate you taking the time to respond to my response more fully. To be honest I was a little frustrated with your previous response. I'd taken the time to try and explain my reasoning and it felt like your response was dismissive. I didn't really feel like spending more time explaining why the link you pointed to was consistent with my perspective.

The accepted answer quotes Fielding and identifies that a "document or image, a temporal service ...."

Which means that I can create a resource called `TripStarter` and consider it a "processing resource" or "temporal service". Using the POST method to pass data to this resource can make unsafe changes to other resources in my system. There is no REST constraint that says a resource must respond to all methods. There is also no reason that a GET method could not return statistics on recently started trips.

You may consider it a contrived example, but that's not really relevant. What is relevant is whether the REST constraints are violated and therefore have a negative impact on evolvability and scalability. Respecting the constraints is the only thing that determines if something is RESTful or not, regardless of "bending or breaking".

I didn't respond to your claim that I was oversimplifying because I believe you missed some words out of that sentence and I didn't think it wise to guess what you were trying to say.

I'm afraid saying "/trips/123/start is a remote procedure (RPC) is not incorrect, that's definitively the case" repeatedly doesn't make it so. Based on the context, "/trips/123/start" is a relative URL. A resource identifier and locator. HTTP has a standardized way of dereferencing URLs. You seem to feel because the word "start" is in that URL that implies some guarantee of its behavior and the way it is invoked. I just don't see that..

Your distinction between "resources" and "procedures/commands/actions" is not an uncommon one. Siren makes this distinction, so does OData. In fact in many cases a HTML form that uses the POST method would regularly be considered an action. However, to try and say that actions are not RESTful is basically saying the HTML based web isn't RESTful. The HTTP POST method quite naturally handles unsafe requests that may or may not create resources.

To be honest, I get the impression that our perspectives are far enough apart that we probably won't reconcile our positions in blog comments.

However, you do seem to hold some weight with Roy's words, so I'll leave you with the following quotes from Roy's post http://roy.gbiv.com/untangl...,

"POST serves many useful purposes in HTTP, including the general purpose of “this action isn’t worth standardizing.”

And when Roy comes to answering Tim Bray's question of how to "deploy" a VM, Roy's answer was:
"I would just use POST for that button"

Re: RPC vs REST is not in the URL

philsturgeon — Wed, 21 Sep 2016 16:40:18 -0000

I'm not entirely sure that's irony, that's mostly an appeal to authority wrapped in a not-so-humble-brag. It's unclear what you're trying to achieve by sending that link. There are a few tags that I score incredibly highly on, but do you think that makes me automatically correct on every single thing in that topic?

You put out some thoughts, I responded with a quick link that outlines articulately what I consider to be the case, then you just flippantly replied with "I tried.". You act like a conversation should only ever get as far as you saying something, followed by immediate agreement.

1. Feel free to explain why the two folks answering that question are mistaken.

2. You didn't reply to me pointing out you're grossly over-simplifying the article. Do you really think my entire distinction between RPC and REST is the URL?

> The details of how its called and therefore the contents of the URL are irrelevant

That's not what I said.

My distinction themes around the differentiation between resources and procedures/commands/actions. Pointing out that /trips/123/start is a remote procedure (RPC) is not incorrect, that's definitively the case.

You can try and bend and break anything into being RESTful, assuming that it is, unless there is an explicit rule saying it is not. That's not really how it works.

https://www.ics.uci.edu/~fi...

REST is about Resources, representing entities. /trips/123/start (in this example) is an arbitrary trigger, not representing anything. You could not GET a start. You could not modify a start. You could not consider a start to be a relationship (in this example).

It is an arbitrary action, and that is the wheelhouse of RPC. As you point out, the R stands for remote, which is why I used the JavaScript examples to show how it would look if it was not remote.

You're coming to some odd conclusions from this article it seems. I don't always write things in a way that literally everyone understands immediately, but I don't honestly know anyone that _can_ do that. Words.

Re: RPC vs REST is not in the URL

Darrel Miller — Wed, 21 Sep 2016 10:15:16 -0000

Ok. I tried. I do find it ironic though that you cite Stackoverflow as one of your sources of learning on REST. http://stackoverflow.com/ta...

Re: RPC vs REST is not in the URL

philsturgeon — Wed, 21 Sep 2016 10:01:27 -0000

Hey! I think that suggesting my article sees the main difference between RPC and REST is a gross oversimplification of a lot of the points.

To focus entirely on whether or not /trips/123/start is an RPC-style endpoint or not... well it definitively is.

Start is not a representation of a resource. :)

http://stackoverflow.com/qu...

I know there is a lot of confusion about what REST is and is not, but my understanding of what I've seen in the dissertation, what I've seen on SO, and everything I've seen from Roy since, agrees with the thoughts I put in the article.

Roy even says that /v1/trips is RPC. RPC is one-off usages of endpoints as cheap triggers, and REST is not that.