RE: Update your STEEM apps! Big changes coming for 3rd party developers
REST only works over HTTP, it's tightly coupled.
I suggest Roy Fielding himself might disagree. It's an architectural style and a series of constraints. It's not HTTP (which happens to follow them).
https://en.wikipedia.org/wiki/Representational_state_transfer
One could fulfill all the constraints and not use HTTP, right? Because Roy was involved in building both in parallel, it's difficult for most to distinguish between the two, but if they can't, it can mean they don't understand what REST is or what the constraints are about.
That said, I agree with you, in a practical sense that today, for most purposes, REST is done over HTTP. I've talked with people who have used different transport layers with custom formats, but really, what's the point unless you have important requirements you have to meet like super compressed binary transport of something.
REST is not the solution for everything by any means. The old REST Discuss Yahoo group was ridiculous in how die-hard they were about REST solving ever problem imaginable. I found the API Craft Google group to be far more helpful years ago when I was learning all this stuff because the recognize what REST is really good for and when it doesn't make sense.
If you've got something that works well for your internal needs, and it's not tightly coupled between the client and the server, than awesome. My personal preference with REST (specifically the hypermedia constraint) allows for loose coupling so the client and server can evolve independently which is really nice. Internally that may be less important unless your application code base and the team supporting it grow too quickly at which point tight coupling can bring you to your knees and require way too much time to test across multiple departments for every code change request.
REST requires HTTP verbs and headers.
Which of the 6 constraints that define REST say that? I linked to the Wikipedia above for a reason. Sure REST "Applied to Web services" typically involves HTTP (verbs, headers, and the rest), but according to the constraints which define REST, it's not a requirement as I understand it. The constraints can be met by other means, if someone chose to do so.
Oh, come off it.
http://www.jsonrpc.org/specification
It's clear what the method/verb is. It's got a field. It's called
method.If I want to transport JSON-RPC over, say, AWS SNS, I simply take the JSON and jam it into a message. Same for a file in S3, or an email, or whatever.
If I want to use a non-HTTP transport for a REST API, I have to invent ways of serializing the keys/values for the headers, the method, the path component of the URI, all of it - I'd be making my own standard.
You are comparing apples to oranges. REST is useful for some things, but what we need is RPC and REST is not very good for RPC.
I'm just trying to speak factually about what REST actually is. As you said, many millennials don't understand it at all.
If you want RPC then you certainly don't want or need REST. No need to defend that decision.
As I said, I'm not personally a fan of RPC because, IMO, it leads to tight client/server coupling. I wrote articles like this five years ago explaining why I prefer REST over something like SOAP because SOAP leads to tight coupling. I bring that up because, to me, many RPC approaches remind me too much of WSDL and SOAP. People start building tooling around them, client generation stuff, etc and before long, we're back where we started with servers and clients tightly coupled. The Internet has worked really well in many ways by keeping clients and servers loosely coupled.
I'm not trying to bust your balls, man. 😊 If what you have works well for you and will continue to scale and meet the needs of the things you'll be doing in the future with an appropriate amount of loose coupling, then fantastic!