> "I threw the code together in minutes and was too lazy to spend another couple minutes figuring out POST." So it's not the vendor's problem then. They provide you with two ways to make a request. You have a choice to do it right, you didn't.
You know how HTTP GET requests are meant to be idempotent?
301–310 of 313 posts
Re: You know how HTTP GET requests are meant to be idempotent?
#302It took a bit of testing before I trusted it would all work the way I thought it would, but now I user it and don't even think about it, it just works and is handy to have.
Re: You know how HTTP GET requests are meant to be idempotent?
#303Earlier quoted context omitted.
> I'm not saying it needs a universal client, just that it's the only real reason I can think of for including all of that. I already gave several examples of reasons why you would do it this way in my earlier comment. Why have we leapt from the garage remote example to a FitBit that tracks vehicle mileage? I don't see why you keep leaping to "it must handle everything everywhere". Stop thinking about handling everyt…
Okay - so to put my question in terms of the garage remote example, say the API offered is_open, open_door, and close_door functions. A "dumb" client that is configured by the server is going to include all three. Image a developer that only wants the UI to be a toggle that mimics an actual hardware button? That would require some a priori knowledge of what the API supports. The list of actions is perhaps useful for…
Re: You know how HTTP GET requests are meant to be idempotent?
#304Earlier quoted context omitted.
I got just the thing for you: https://gist.github.com/hraban/10c7f72ba6ec55247f2d Every time you write some code you need to remember removing before commit, surround it with a comment containing "NOCOMMIT". With this script as a pre-commit hook, git will echo an error message and fail. E.g.: print("debug: ", myval) becomes: print("debug: ", myval) # NOCOMMIT I end up relying on this every day I program. Can't go bac…
Thanks! I'm not sure how easy it would be to put the git hook on all my machines though? I have a collection of laptops (and one desktop) that I work on and I often don't use the same machine for a few weeks :-/ I ended up using a "env.h" file... is there a C-equivalent of the PHP (?) .env file?
Re: You know how HTTP GET requests are meant to be idempotent?
#305Earlier quoted context omitted.
I think there was a homepage with a "toggle" button, the toggle button redirected to /toggle. site.com/toggle then got added to his favorites by safari. So it wasn't loading the site with the button, but the site that the button redirects to.
Correct. Site now has a form and a button. /toggle now responds only to POSTs, and redirects back to /.
Re: You know how HTTP GET requests are meant to be idempotent?
#306Earlier quoted context omitted.
Adding Wi-Fi control to your garage door using a WeMos is not over-engineering. It's just a fun little weekend hack.
Over-engineering is what I did... - Raspberry pi - Open/close sensors on the garage door as well as the side-entry door - Camera pointed at the side entry door taking photos while it is left open - Push alerts to my phone if either door is opened between specific hours of the night (Break-ins to detached garages were huge in my neighborhood) - Voice controls from my fucking phone to open the door I sold the house oth…
Re: You know how HTTP GET requests are meant to be idempotent?
#307When I recently added 'click to unsubscribe' functionality to my emails, the URL got wrote out into some logs. Those logs got written to a Slack channel and Slack loves to click any link it sees. Oh, and it doesn't respect robots.txt. But all I saw was every member of my list clicking 'unsubscribe'. It took a good hour to figure out exactly what was going on. Idempotence is not the problem here, by the way. That just…
Aren't you allowed to have your "click to unsubscribe" button lead to a page with a button that does a POST that actually unsubscribes? I feel like I've seen that approach in use.
The page in question could also have a "actually, I do want to unsubscribe, I just clicked the wrong link by accident" button as well, in case a human reader is confused.
---
Or, one link that says "unsubscribe immediately" and another that says "unsubscribe only after confirmation", and the first one unsubscribes immediately, unless they also click the second link immediately before or after, while the second link only unsubscribes them if they click a confirm button on the page?
---
Or, maybe the unsubscribe link could have a confirmation button, but would also have some javascript to confirm the unsubscribe after a few moments of the page being fully loaded (the button being used if they have javascript disabled, for example)
Re: You know how HTTP GET requests are meant to be idempotent?
#308Earlier quoted context omitted.
Okay - so to put my question in terms of the garage remote example, say the API offered is_open, open_door, and close_door functions. A "dumb" client that is configured by the server is going to include all three. Image a developer that only wants the UI to be a toggle that mimics an actual hardware button? That would require some a priori knowledge of what the API supports. The list of actions is perhaps useful for…
I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.
Going back to the garage door example. Say I'm building a wifi opener. It's going to have one button that acts like a toggle, just like regular garage door openers. Press the button and the door opens. Press it again and the door closes.
In the firmware, it will contact the opener server and it can get a list of actions and endpoints. But if version 2 of the server changes the action name from open to door_open, then my button is broken even though I've diligently followed the HATEOAS model.
Re: You know how HTTP GET requests are meant to be idempotent?
#309Earlier quoted context omitted.
I've been diligent about HATEOAS links for years, but recently stopped bothering. They've never actually been used in practice. While the concept of a universal HATEOAS client has been around forever, there's no real world use case for them. The whole idea is a solution looking for a problem.
I still am having a hard time with the concept. Going back to the garage door example. Say I'm building a wifi opener. It's going to have one button that acts like a toggle, just like regular garage door openers. Press the button and the door opens. Press it again and the door closes. In the firmware, it will contact the opener server and it can get a list of actions and endpoints. But if version 2 of the server chan…
But what was misunderstood in that vision is that context can't readily be conveyed through some simplistic HATEOAS verbs. In the real internet of internets, with browsers and HTMLs, you have help links, positioning, colors, animations, highlighting, decades of UX research to help people understand what the various buttons do. HATEOAS was supposed to provide this in an automated way as a "browser for APIs", but ultimately the concept is far too simplistic to guide anything beyond an obvious CRUD model. And for an obvious CRUD model, well, it's unnecessary.
So anyway, that's my position after a decade of experience with it.