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.
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!
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!