Let's put "REST" to rest because no one can agree on what it means.
It's time to put REST to rest
31–40 of 85 posts
Re: It's time to put REST to rest
#32https://en.wikipedia.org/wiki/XML-RPC (1998)
A tool best used to communicate SQL queries to the server (yes, I've seen it in production).
Re: It's time to put REST to rest
#33> About being able to use a RESTful API directly from a browser: browsers only use the GET and POST HTTP methods, among the ones REST associates meaning to. You cannot use a RESTful API from the browser, because the PUT, PATCH, and DELETE methods are not used by the browser, and even the POST method cannot be used without a UI. Also, even if you could, APIs are for machines, not humans. The user experience would be d…
They mean you can’t interact with a raw API from the browser. Unless you are just doing vanilla gets.
You might use a REST client instead or what some services do is offer a playground coded in JS to play with the end point but such a playground needs to deal with CORS.
Re: It's time to put REST to rest
#34If I had to guess, the comments here are going to revolve around "that's not REST" and "where's the hypermedia." I think that ship has sailed. REST in practice just means following HTTP semantics.
Whatever you say REST is, Roy T. Fielding will come around to tell you that it isn't that.
Re: It's time to put REST to rest
#35If I had to guess, the comments here are going to revolve around "that's not REST" and "where's the hypermedia." I think that ship has sailed. REST in practice just means following HTTP semantics.
> REST in practice just means following HTTP semantics.
If that were true, it would be awesome. Because full HTTP semanics are quite intricate, and cover a lot
- HTTP decision diagram: https://github.com/for-GET/http-decision-diagram (full docs: https://github.com/for-GET/http-decision-diagram/blob/master..., just the PNG: https://camo.githubusercontent.com/c26df6d372790e9f24d7e16d2...)
- Know your HTTP well: https://github.com/for-GET/know-your-http-well
Re: It's time to put REST to rest
#36Earlier quoted context omitted.
Well, if we're being truthful, none of us use REST. We're all just cherry-picking the parts of it that work for our organizations... and that's absolutely fine . The programtic discoverability portion of REST always struck me as pretty poorly thought-out anyways.
You use REST every day. HTML is REST. Yes, with HATEOAS.
[deleted]
Re: It's time to put REST to rest
#37I went into this article strongly disagreeing but I think the alternative presented at the end are valid ways to structure an API and for those who very loosely follow REST structuring would probably consider the alternatives "REST" too.
REST seems to have different definitions depending who you talk to. Some define it very strictly (as the opening of the article seems to do) and others define it very loosely (as a JSON interface with GET/POST/etc commands). For those who implement REST loosely, the suggested alternatives fit right in.
Re: It's time to put REST to rest
#38I agree with some of this - I've never found value in the different PUT/PATCH/etc verbs, and I think the lack of examples of good "pure" REST APIs indicates that pure REST doesn't work easily for most projects. I do think this throws away some pieces that are really valuable though: 1. URLs for concepts are a good idea 2. Distinguishing between read-only operations (which can be cached) and write operations using GET…
1. URLs doesn’t matter in REST because interactions are hypertext-driven.
2. The method to use is implied by the relationship of a link.
Re: It's time to put REST to rest
#39A thing not being mentioned is caching.
Now I'm not a web dev, I've played around way back in the CGI era and since then moved on to other things. But my impression was that part of the point of REST was making it fit in a bit better in how the protocol is supposed to behave.
Early on there was a lot of stuff that did nothing but GET for everything. Done that way any layer in the middle can't make any sensible caching decisions, and even the logs are annoying to look at when you can't quickly tell apart what's retrieving data and what's changing it.
So my impression was that part of the point of REST is to shoehorn an API into something that makes sense in the way HTTP is supposed to work, and you're less likely to have something go dramatically go wrong because some cheap ISP is running a transparent proxy and deciding that the GET that's supposed to save something doesn't actually need to happen, because look, this user already made a GET to the same URL 5 seconds ago.
Now of course today everything uses SSL, but early on it wasn't that weird to run into some awful ISP that would do some sort of aggressive caching to save on upstream bandwidth, if not to actually try to recompress stuff in flight.
Re: It's time to put REST to rest
#40The trading example is bad, since we do talk about posting limit orders even outside of a REST context -- though it refers to it staying in the book and not matching immediately.