|
And do they know the truth about St. Paddy?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
Does that include the ouroboros? Or is that one just eating it's past events.
Sin tack
the any key okay
|
|
|
|
|
Do smart snakes study viperspace ?
... such stuff as dreams are made on
|
|
|
|
|
Snakes on a Plane Space Ship??
(actually really useful if having Trouble with Tribbles)
Sin tack
the any key okay
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
