171–180 of 313 posts
Earlier quoted context omitted.
Not if the button issues a POST request.
The button I was responding about was an "undo unsubscribe". A bot won't click that button, but may follow a link.
My desk height is set with a GET. I was going to fix it, but considering how hilarious this is I might not.
Earlier quoted context omitted.
It's pretty simple – the information a client needs to transition from one state to another needs to be encoded in the documents. So if you were to design a garage door opener, a non-REST specification might say something like: To get the door status, GET https://example.com/status To open the door, POST to https://example.com/open To close the door, POST to https://example.com/close A REST approach might use a docum…
The problem I have with that explanation is that it seems to assume the existence of a universal client. How many clients are examining responses and using that to build up a UI for actions with no anticipation of what those actions might be?
Earlier quoted context omitted.
Don't make your users jump through hoops to unsubscribe. That seems like a typical dark pattern to me.
Having a single confirmation step to prevent "oops" clicks doesn't seem like a dark pattern to me.
I have seen this with spam, and I have seen it with DMCA requests. My hosting provider will issue me a warning for any DMCA request that they will shut me down within 48 hours if I don't comply. Even when it is clearly not a valid request. Even when the content has already been removed. They don't even check, they just say "do it or else". And I pay them thousands per month. Godaddy is the same way, I have had people complain to them, and then they threaten to shut down the domain.
When you have been threatened repeatedly to be shut down for operating normally you don't take any chances. It isn't worth it.
The real problem here, as usual, is web browsers, the worst class of software ever written. We constantly come across these CSRF-style bugs that are only made possible by how stupid the browser and HTTP are, but instead of blaming the culprit and trying to deal with the source, we blame ourselves for not being accommodating enough. Fool me once, shame on me, fool me 5,000 times, shame on me. Oh, and occasionally inve…
Hope for the best but expect the worst.
I know this is quite unrelated, and based on hazy memory of things from almost 10 years ago, DML statements in databases especially 'insert into' statements are not idempotent as I remember; ie if you try to select a few rows from a table table1 and insert them into table2 with same schema, if there were any identical rows already in table2, then whole insert will fail. My thinking at that time was that if these inse…
GET is actually supposed to be safe which is stronger than idempotent; the SQL command that most naturally corresponds to GET—SELECT—is normally safe, but DML inherently is not.
But, sure, that INSERT isn't safe increases the amount of code needed to implement idempotent PUTs.
Earlier quoted context omitted.
> you'd build a REST application Nah, nerds would come out of the woodwork to inform you that what you've built is not a real REST.
Yeah - there's always a HATEOAS comment somewhere and I've never really managed to figure out what that means beyond using URI's rather than a database IDs + some documented endpoint path to point to other resources.
The problem is people thinking HATEOS is a requirement for web services.
Earlier quoted context omitted.
It's pretty simple – the information a client needs to transition from one state to another needs to be encoded in the documents. So if you were to design a garage door opener, a non-REST specification might say something like: To get the door status, GET https://example.com/status To open the door, POST to https://example.com/open To close the door, POST to https://example.com/close A REST approach might use a docum…
The problem I have with that explanation is that it seems to assume the existence of a universal client. How many clients are examining responses and using that to build up a UI for actions with no anticipation of what those actions might be?
This kind of thing shouldn’t even be a REST call. Use JSON RPC.
When 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…
> Idempotence is not the problem here, by the way. That just means calling the method twice has the same effect. But GET should have no side-effect, in an ideal world. Of course, in the case of unsubscribe links, it needs to have a side-effect to comply with the law. Thank you! I felt like I was taking crazy pills with my understanding of idempotence. Calling GET /door/open is idempotent too, but it's still gross in…