That was exactly their implication. "We don't go for that open source crap" is a motto of theirs. Usually it's just obnoxious. This time, they just happened to blindly fall on the right side of the line.
-26 karma · joined January 4, 2014
This sentence physically hurt to read. I seriously hope that Google Translate wrote this.
What might be interesting is being able to import and export configurations to standardize git usage across multi-coder projects?
What? Is he sticking a copy in the mailbox for everyone who downloads it? I hope that's a translation error, because it simply makes no sense.
Yes, RPC is better suited for complex abstract actions where you don't have a resource as a context, whereas REST is better suited for resource-based access and actions. Both should have a place in your toolbox, and to say that one is superior to the other is simply trolling for a religious war.
REST is not relegated to CRUD, and is being grossly misrepresented when it is said to. SQL is a scripting language, not a RPC or REST API. If you can make SQL into a RPC, I'd love to see it. It must be absolutely nasty.
RPC is great for situations where you don't necessarily need an answer, or the answer is so abstract that it doesn't really relate to a specific resource. The great thing about RPC is you usually have something like a WSDL that many tools can use to generate your client code for you. It makes it very easy to implement into your client project, but can be very brittle, as any changes to the WSDL will break the client.
REST is great for when your actions revolve around resources, whether they be actions or access. Not everything needs to be relegated to the URL. You can post or put just about anything in the body, including SQL if you were so inclined (please don't ever do something like that). The thing about this is you're using the resource in the URL as context, so it's a different way of modeling your API. Though there is WADL and a couple of other standards for describing a RESTful service, none of them are well accepted and there is poor tool support for generating client code for you. This is a disadvantage in that it forces you to roll your own code (which probably averages about 5 lines per call), but is an advantage in that you can easily follow a "tolerant reader" methodology which makes your client highly resistant to API breakage.
If you're smart, you'll use HATEOAS in your responses. It may not be used by all clients, it's up to them, but it does allow flexibility if they do use it. We've had great success with it at the Fortune 100 company I work for.
I agree that many people use REST as a marketing term and don't fully understand it. Those who do though are using it successfully and enjoy when the opportunity to use it for their project. The important thing is to remember that both are important and not try to fit one into a hole that calls for the other.