4 ms·

Are you assuming REST is easier than RPC to develop and/or consume? After moving to a REST based API there were endless meetings between co-workers of what is

by pixie_ 9y ago

Are you assuming REST is easier than RPC to develop and/or consume? After moving to a REST based API there were endless meetings between co-workers of what is and isn't a good REST url. Our clients often come to us with dumb mistakes. Unlike RPC where the parameters go in a single place. With REST the parameters are spread across the verb, url, header, query param, etc..

assafmo 9y ago
Yes, I'm assuming REST is easier because of tools like curl, postman and even the major browsers with HTTP GET and great dev tools. With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library. So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net https://freegeoip.net - where the client can test the API in a few seconds by copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.
- zo1 9y ago
  I don't really understand the debate here regarding tooling. REST, SOAP and RPC are all ways to define/codify the API and the parameters. It all goes over HTTP at the end. So Curl, postman and all other HTTP-enabling tools/libraries can be used. SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages. It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.
- mgkimsal 9y ago
  It's precisely the 'simple' examples which don't address any of the complexities in the original article. read-only properties in a resource being PUT back, for example. You're not having to deal with that with simple read-only services like freegeoip.
jrochkind1 9y ago
I think they were suggesting that it was more difficult to design/develop (as per your example), but easier to consume if designed/developed well, and that this was the proper tradeoff.

by pixie_ 9y ago

assafmo 9y ago

Yes, I'm assuming REST is easier because of tools like curl, postman and even the major browsers with HTTP GET and great dev tools. With RPC your consumers probably need to know some coding and even maybe a specific language, a framework or a library. So yes, for me REST is easier, and I always love to see landing pages like this one - https://freegeoip.net https://freegeoip.net - where the client can test the API in a few seconds by copying an example to its browser address line. This is a simple use case, but I hope you get my meaning.

zo1 9y ago
I don't really understand the debate here regarding tooling. REST, SOAP and RPC are all ways to define/codify the API and the parameters. It all goes over HTTP at the end. So Curl, postman and all other HTTP-enabling tools/libraries can be used. SOAP even has handy discovery tools that frameworks can consume and construct entire APIs in most popular languages. It's just that no-one uses SOAP from a browser because XML is a royal PITA to write in JS. I would assume it's because all JS developers are too-busy writing more libraries-for and layers-over JSON.
mgkimsal 9y ago
It's precisely the 'simple' examples which don't address any of the complexities in the original article. read-only properties in a resource being PUT back, for example. You're not having to deal with that with simple read-only services like freegeoip.

jrochkind1 9y ago

I think they were suggesting that it was more difficult to design/develop (as per your example), but easier to consume if designed/developed well, and that this was the proper tradeoff.