6 ms·
And REST is easier to debug. This make a huge difference when you have a big and complex system.
by felipelemos 9y ago
And REST is easier to debug.
This make a huge difference when you have a big and complex system.
- harryf 9y agoAnd caching is easy to implement independently of the API using a proxy
- lfischer 9y agoHow exactly do you think REST is easier to debug and what alternatives are you comparing it to?
- ivan_gammel 9y agoCrafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).
- ern 9y agoI don't mind a loose JSON REST-ish API, where everything is a GET, POST or (maybe) a PUT, with explicit endpoints to resolve ambiguities. Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.
- deeringc 9y agoThe author was comparing REST to json-rpc. Nowhere in the article does he propose that people use SOA or CORBA.
- ivan_gammel 9y agoThere's no difference between debugging REST and JSON-RPC over HTTP, so there's no point to compare them. The other alternatives, that I've mentioned, are less easy to debug.
- 0x445442 9y agoThat is highly dependent on the language you are using. Many languages support auto generation of consumer and producer code based off of WSDLs. And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.
- ivan_gammel 9y agoIt's still much faster to run curl with JSON, than to run auto-gen tool and write a whole test program to call an API.
- mamon 9y agoHave you ever seen SoapUI tool[1] ? It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl. [1] https://www.soapui.org/ https://www.soapui.org/
- barrkel 9y agoGET / POST RPC is just as easy to debug, IMO, and with less righteous orthodoxy.
- mseebach 9y agoThe orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot. If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
- barrkel 9y agoYou need a standard within the ecosystem you play in, if only to reduce the amount of work integrating bits and pieces. For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update). But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
- ams6110 9y agoSome http clients can only do GET and POST. If your API demands PUT, PATCH, or DELETE it may be less useful.
- gozur88 9y agoThe nice thing about SOAP was it had a full-fledged type system built in. REST is certainly easier to debug, but it's also more likely you'll be required to debug it, since many of the problems you'll run into in a REST interface would have been caught at compile time with SOAP. SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.