3 ms·
If you are mapping your RPC-style API into a REST interface, you are doing it wrong. REST as an architectural style wants you to think as your API as a collect
by beders 12y ago
If you are mapping your RPC-style API into a REST interface, you are doing it wrong.
REST as an architectural style wants you to think as your API as a collection of resource representations that can be manipulated through simple verbs (as the one present in HTTP).
It forces you to think about idem-potency, caching, namespacing, immutability and robustness.
If your API doesn't have abstractions for long running processes or more complex business transactions, you don't have a RESTful API and need to adapt it.
Furthermore, if payload size and minimizing the number of requests is your most important goal, why are you using HTTP in the first place? It's not the right solution for you.
- stupidcar 12y agoAnd object orientation wants you to think about your API as a graph of objects, but going too far down this rabbit hole is how you end up with a mess of AbstractSingletonProxyFactoryBeans[1]. Yes, it's possible to adapt any system into a collection of resources, but the transformations necessary to do so can end up creating more complexity than is gained through only having resources and verbs. The supposed simplicity of REST can be like the simplicity of the Brainfuck language. There's only 8 commands! Easy! And the idea that using HTTP somehow renders questions of performance irrelevant is bizarre. If Hacker News sent 10MB of uncachable CSS, spread over 100 HTTP requests, with every page load, would that be OK because performance isn't the most important goal of the web? People use HTTP because it's a ubiquitous protocol supported by virtually every device and language. Performance isn't the most important goal, but it's still an important one. [1] http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.co.uk/2006/03/execution-in-kingd...