|
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
|
|
|
|
|
fast.ai · Making neural nets uncool again
Just go there. So far, I'm quite impressed by their teaching approach.
Marc
Latest Article - Merkle Trees
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
And yet after reading bits and pieces of it I have absoloutely no idea what they do and even what the intent of that site is.
"Machine learning as a service"
What the f*&^ is that supposed to mean?
"data scientist"? 
"Why you (yes, you) should blog"
Just what we need, more opinions on the net.
modified 24-Apr-17 9:25am.
|
|
|
|
|
The breadth of your lack of knowledge is staggering.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Thanks, I needed a laugh!
|
|
|
|
|
|
Yeah, I eventually stumbled in that page. It at least explains what they are doing, just about, but its very vague still.
--edit--
"In this course we don't just show how to create "OK" models. We show how to create state of the art models,"
Right, so its a course to teach mathematical moddeling.
So it looks like two people in San Franciscoi met. She is a moddeler, he is an 'entrepreneur' and 'educator', and thought 'hmm, if I take all that she knows I can dress it up as 'Deep Learming' and 'Machine Service Assisted blah blash blah' and foist it on people.
--edit--
I mean look. I dont mean to be disparaging, and I am all for learning usefull stuff, but to have something like this aimed at coders, and to be so vague, and then to be, quite frankly, of limited application (I know some of us work with models, they tend to be mathematician types, and probably know alot about moddeling anyway) was a dissapointment.
It just didnt grab me the way it seemd to grab you.
Sorry.
modified 24-Apr-17 10:22am.
|
|
|
|
|
Be assured that those of us with brains agree with you, Marc.
The site as it stands has the potential to draw people in, get them interested, and put them on good roads to learn what they need to work on AI.
I've worked quite a bit in the AI field, and getting people to learn to walk in it is not as easy as it sounds. The site is a good starting point, and I will be sending people to it.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: Be assured that those of us with brains agree with you, Marc.
I was never worried. Thank you for kind words!
Marc
Latest Article - Merkle Trees
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
ok, go here instead: