![]() Simple conventions make interacting with REST APIs fairly straightforward. Verbs are associated with operations (making simple a mapping of CRUD operations for example), entities lend name and meaning to URIs. Most of transport concerns are handled by existing standards and evolve with it. While JSON is the most common content type for REST data, XML is not unheard of and HTML itself is available.īuilding on the existing standards of HTTP comes with both flexibility and constraints. This has led to the existence of a lot of best-practice scenarios around REST, that deal with the unsaid: how to define and organise URIs, the boundaries of the data manipulated at a given URI, how to encapsulate data, how and what to return, etc.Īnother important property of REST services is statelessness: no context should be preserved between requests, each is treated in isolation and must have a finality of its own. In fact, it's so popular that it's the thing people think about when someone says "API", nevermind the web (or HTTP) part.Īs a standard, it's surprisingly lightweight as it only specifies the use of HTTP and HTTP concepts (verbs, codes, states, etc) in order to access remote entities found at various URIs. The REpresentational State Transfer is probably the thing most people think about when someone says "web API". Support for code generation in modern languages is lackluster (your best bets are Java, Python and C#, while SOAP with the likes of Go/Rust/PHP/Elixir are exercises in frustration).Īll in all, SOAP is all but dead in favour of more flexible and efficient communication methods (though my nightmares have returned after a few projects around insurance and banking). By necessity, SOAP is one way (as in a client can't be also a server and the other way around - even if both applications can act as web servers). ![]() XML is very verbose and message size tends to grow exponentially. Since the procedures are described in a WSDL, the file acts as a binding contract with respect to messages and types. As text-based standard it's easy to debug and has no restrictions in transport. SOAP allows for code generation based on XML, XML is (was) a popular and ubiquitous standard with plenty of flexibility (eg: namespacing). I bet you're seeing where the simplicity has gone to die. This requires the service to define the available procedures, its parameters and types, content format, responses, etc in a WSDL that defines the service while it also needs a bunch of other XML-offshoots (XSD, etc) to define custom types and objects. It communicates using XML content over HTTP (mostly, but the transport isn't a part of the standard - so it could be used over anything) for the specific goal of invoking procedures exposed by a service. The "Simple Object Access Protocol" (though largely this meaning has been rightly forgotten since it's anything but simple) is the oldest system for data access as well as the bane of my university years. Each of these allow an external entity to access your data within some boundaries. What unites them is the general idea of transferring control of data manipulation. ![]() While the first two are (were) traditional competing "standards", the other two are a bit different in scope. As far as comparisons go, this might seem a bit weird. ![]()
0 Comments
Leave a Reply. |