|
In Space Nobody Can Hear You Hiss
... such stuff as dreams are made on
|
|
|
|
|
Oh mamba, that's a terrible pun.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
It would only do that if it were a cobra (Cleo's snake). If it were a rattlesnake, it would be Calliope's.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Is a royal snake a Hisstocrat[^]?
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
That argument doesn't have a leg to stand on.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Does that definition scale to a group? "Group Hiss! Altogether now!"
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I'll let you know venom amused by your puns.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Even before everyone got fascinated with REST and APIs, I was fascinated with AJAX and used to make web pages that would carry on JSON conversations with the server. The basic structure of the message was {"error:"", "command1":"", {Data":""}... to be modified and expanded as needed both to and from the server. You would put a Command Pattern on Client or Server to determine what to do or where to route the request/response based on the command. "error" was universal! The best or only way to manage this was with a POST statement and it worked dandy as a Web Method in an ASPX page or even better in an ASHX page.
So my question is - why the elephant do we use Get, Delete, Put, Post? Why separate the verb from the message? Why do we use the shape of the message to determine the action associated with the message? We all know that we have to do a little work around to that pattern anyway every time you need to distinguish between getting one object of a type and getting all objects of that type. It just seems such a silly way to manage a message transaction. Also, it really doesn't manage errors. It does not plan to send an error message or action from the server to client. The client just knows there was an error.
Can anyone explain why it is done this way other than just habit?
|
|
|
|
|
The only true rest as defined by the dissertation of Fielding has to be a GET request. Because POST requests are actually not unique URLs. I also use POST exclusively when building JSON services.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I gave a rest to REST very early and use only POST with similarly packed data to yours...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Probably just because those are the HTTP verbs I guess, and to try and make use of them. I know where you are coming from; Put vs Post is confusing. And generally when I do this sort of stuff, which isn't often, I use Get when you can get everything in the URL, and post when the inputs are a bit bigger.
I don't know whether that's proper REST or not, but seems to be common sense and it works. Purists might argue that a GET shouldn't be able to change state.
Regards,
Rob Philpott.
|
|
|
|
|
|
Well they certainly don't seem to have any objections, but I do agree we need a new verb - "crashed".
Well, I sure don't seem to be hearing any push back. Maybe the the objections are coming from the Business folks selling the API movement without knowing any details about it.
|
|
|
|
|
I agree, and Fielding seems to point the same thing out at end of the discussion, bottom of the page:
Quote: William, I talked about the phenomenon of design-by-buzzword in the introduction to my dissertation. It doesn’t surprise me that software companies and consultants continue to use the same marketing and design tactics, even after they’ve updated their buzzword vocabulary to include REST.
Nevertheless, there are plenty of information systems that can be designed using the REST architectural style and gain the associated benefits. Managing cloud instances is certainly one of those applications for which REST is a good fit, as Stu Charlton has described several times. I am glad that Tim and others in the Kenai project are making the attempt, even if the first few iterations have some warts, and I approve of his stance that the design constraints of REST should be used when they are useful, not just because they are RESTful.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
The only justification I use to separate functional capabilities between GET, POST, PUT, etc... is because if I didn't, I'd be rebuilding something that likely already exists as part of my server software.
I write business code, not HTTP server code, so I'll let the server route the verbs appropriately, and I'll write my business code in the appropriate handlers.
|
|
|
|
|
Do you mean the ASP.NET MVC routing? In MVC you are indeed boxed in to use the system routing as it is, but outside of the Microsoft MVC handlers you have to roll your own implementation. (Just like outside of Entity Framework you roll your own data layer)
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Not just .NET based servers: node + express or Apache Camel/CXF. The ability to set up a "Get" handler vs a "Post" handler vs a "Put" handler is trivial in all of those environments. If I set up one catch-all "Do Everything" handler, then parse my payload to figure out what I actually have to do, then dispatch to the appropriate method, I have just written some (non-trivial) code that has nothing to do with my company's core product.
|
|
|
|
|
ok, I get it, however at least in MVC they all don't go full REST for delete per example. They use POST with ActionName - Delete, which is another parameter, things get even more screwed up when it comes to partial updates of an object.
Per example if you want to update just the phone number of a person object, you either have to retrieve and update the whole person, or create routing for phone action, am I right? So in the end you end up writing some logic anyway or will have lots of additional routes.
Edit: actually what I'm asking is what is your preferred approach with partial object updates?
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Termi Nater wrote: what is your preferred approach with partial object updates?
There's a verb for that as well 
PATCH
I'd still need the person Id, though, and chances are I will have already hit a GET endpoint to pull data to display on the UI that lets my end user make the edits I'm going to ultimately persist. So my use cases for PATCH are few and far between. About the only time I use PATCH regularly is when I have an auto-save form that sends the partial object back every time you dirty a field, then tab out of it. If I still require my user to click a button to save the data, then I might as well just send all the fields and use PUT/POST.
Of course, I haven't done any .NET-based server stuff in a couple years. These days my back end is a Java ESB, so I have access to lots of verbs (including DELETE as a real verb - not the weird actionName thing that MVC puts you through). .NET core might be better in this regard, but then you're writing a lot of route handlers in there anyway, so until that ecosystem starts getting more robust, I will probably stay away from it.
|
|
|
|
|
Thanks,
Quote: so until that ecosystem starts getting more robust, I will probably stay away from it.
Or as in my case you roll your own implementation, where you don't have to fight the already baked in restrictions.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I've gone back and forth a few times over the years on this one. I've spent a lot of time using POST-only operations with SPA's using a wrapper structure to define things like command and control, mapping functions, and data transactions.
I sat down a few months ago to work on a new pet project and as I was starting to wire up the request handlers I started to realize exactly what I was doing wrong: I was mixing my operational requirements with my data payload. Those two things will never exist in isolation and if anyone else wants to use my data they will need to do it on my terms.
Any use of my micro services required an interpreter for my structure; therefore my software was not a good and cooperative member of the ecosystem.
That's where I started to really think about the point of REST. I've had so many managers throw that term around that I've basically taken to ignoring it; it can easily be decomposed into a buzz-word that now encapsulates almost any SOA.
But that's not the reality. REST provides a framework that takes certain very reasonable assumptions and turns them into a communication strategy. Those assumptions are almost solid enough to be called "givens". The first is this: the basic foundation of web communications is that we ALL agree on a protocol to enable communications. The second: the important part of a transaction is the DATA, not the structure containing it. The third: to enable actual interoperability, we can rely on an agreed upon data format such as XML or JSON.
That was the lightbulb moment for me. To be a good actor in a diverse environment, I need to provide the formatted data without my own c^2 BS. That's where the really clever parts of REST come in: we have ALREADY agreed on a protocol and a format, and we can leverage those to provide the important bit, the data. By using REST, we can abstract the command and control to the protocol, which already has stimulus/response mechanisms wired up. The DATA becomes the point again, and that's exactly how it should be.
More to the point, REST provides a baked in C^2 strategy that can be used in a convention-based manner, rather than the negotiation that needs to be done for protocols like SOAP. By providing handlers in a convention-based manner, we provide data that anyone can hook without needing to lean on a .wsdl or other definition document; the definition is baked into the strategy.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Excellent response. Excellent.
So when making an API, you would want to properly use REST... As you say to avoid the need for wsdl or something like it. My only objection is that what you say is only 100% true in a perfect world. Sometimes even in REST, there can be some ambiguity such as returning a single item or a range of items. Still, an excellent point to be kept in mind and certainly should be followed in principle.
Now as a different point, since I am not making an API or even MicroServices, I can say it's valid, because I am carrying on a conversation, not even doing a query. In this case, I'm not even using a command parameter (incorrect, I am too), I'm sending a data packet to the client with all the data needed to update a dashboard. The client can send some parameters though that change the data selection parameters, but not the members of the data.
|
|
|
|
|
And that's exactly the approach that I've taken for years. But the reason that I advocated for the SPA in my organization was so that we could stop re-inventing the wheel every time we needed to re-use a data element, and my own internal implementation has mirrored what a lot of other commentators in this thread have done: create a response wrapper that contains operational data bundled with the actual application data. Over time I've come to realize that's a mistake, for exactly the reasons that you were asking about in your original post.
I may not have highlighted it well, but the way that I see this is as a tight-coupling pattern. My web modules are building a C^2 structure around my data because it's an easy way to coordinate actions between the client and the server. What I (well, we) have really done there is create a new protocol, that is layered on top of a protocol that can already handle all of those needs. But what about other potential data consumers that we might not even be considering? That is the question that REST answers.
By separating the operational data from the application data using REST we're using an accepted standard, like any good craftsman should, and it can be understood and interpreted instantly outside of the scope of our application. This is a pretty big deal right now, especially when you consider the complexity of the alternatives (there is no such thing as a simple ESB, for instance). even data that you may consider trivial might be especially important to another party, and REST can help facilitate its use.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
So ... what if someone else besides my dashboard needs to consume part of that data? That could easily come to be... As a matter of fact, as a stopgap measure, we have given them a SQL query that does return three of the statistics used by the dashboard.
OK, I'll try one last time to support my strategy... Be gentle.
I am doing a select of all data in the last 24 hours and doing a complicated analysis of it. That is why only three statistics can come from a SQL Query. I do one query for all my data... and it's a lot. I make statistics based on current state as well as the past 24 hours. I even have to interpret invalid data and I need aggregations of the data that is current... and the 24-hour data. I don't think I can achieve all of that with single queries and certainly not efficiently.
Now, I still really like your argument, so I think I'm going to add normal REST functionality for what I can... All projects are learning exercises... I have the code for the rest of the stuff. ... Hmmm, though I am cheating and not using routing, so it may not work. This is all based on a single HTML page and a single ASHX page for simplicity sake.... I may just be stuck with using your well laid out and well supported argument for future projects. Thanks a lot for the illumination.
|
|
|
|
|
That's exactly where I'm at as well.
Good luck!
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
