3 ms·
> "REST is nothing but loosely connected guidelines that nobody uses in the same manner" But is that really a huge problem? Look at more rigorous rpc standard
by throwaway5752 10y ago
> "REST is nothing but loosely connected guidelines that nobody uses in the same manner"
But is that really a huge problem?
Look at more rigorous rpc standards with more rigorous standards and formal interface definitions: RMI, xmlrpc, CORBA, SOAP, Thrift, AMF... I'm sure there are loads and loads of real world systems using these and they have their place, but REST has succeeded in a large niche that they have not.
- toyg 10y agoThat's really the winning point of REST: it's just formal enough to put most people on the same page, and loose enough to adapt to different requirements without too much effort. It's useful to remember that REST was borne and adopted mostly in reaction to SOAP and XMLRPC (which in turn were basically replacing CORBA and RMI to work around the firewall). XMLRPC was too loose, and SOAP was too formal (way too formal). REST hit the sweet spot. However, it's sad that the result was often that people just retooled their crappy SOAP / RPC systems to use decent URLs and called it REST. My litmus test is usually "returning 200 OK on all calls" - if you're doing that, that's not REST. Use proper HTTP return codes and put additional error messages in the payload, it's not hard. Also, if you have a job queue, give each job a URL with the ID and GET that to retrieve status.