20 ms·
I don't hear people talk about the design side of services vs libraries enough, but I think it's a huge part of the picture. Many people reach for services too
by wcarss 6y ago
I don't hear people talk about the design side of services vs libraries enough, but I think it's a huge part of the picture.
Many people reach for services too fast because they feel more comfortable thinking about APIs through the lens of HTTP verbs and resource URLs than they do in the comparatively infinite garden of options inside a program.
The REST paradigm, despite most people not understanding, needing, or utilizing it fully, has out-competed most other software design memes. It was well-positioned to do so, with its creator being an author on the HTTP RFCs and the internet exploding in popularity and use right as the work was published.
REST (and earlier, SOAP) also had good business/network reasons to become very well known: a business who wants you to integrate with them must tell you about their integration pattern. They need to document it and motivate it. Then people have to actually write a lot of software that works that way, over and over. Exposure spreads at the speed of business, and a broad culture of REST-knowledge was inevitable, as was an industry of teaching it. Learning "REST" has long been a compulsory part of learning web-interfacing development.
By contrast, can you name a similarly restrictive organizational zeitgeist for internal program structure?
Domain Driven Design, maybe? The broad concept of "design patterns"? "OO"? None of these are anywhere near prescriptive enough to answer the classic question, "how do I organize this greenfield project from scratch?"
Maybe someone could take a restrictive set of best practices for internal API design, write a dissertation on it, give it a great name (like NICE) and then proselytize it effectively enough to gain mindshare and improve the design options available. (This seems like an interesting marketing problem as much as it is a software design one!)
As it is though, most people just don't know any other consistent, repeatable way to break a complex system down.
- ahepp 6y agoSOAP doesn't have anything like the restrictions rest has, does it?
- lostcolony 6y agoIt doesn't, but also, services were far less common compared with libraries when it was popular.
- zo1 6y ago"REST" these days is a defacto code name for "(JSON?) calls over HTTP", with loosey-goosey adherence to anything close to what the original REST author meant. At this point, we might as well call it RPC-style organized calls over HTTP using JSON representations and defined by "Swagger" files. Likewise, most of SOAP was "RPC-style organized calls over HTTP (or TCP) using mostly XML serialization and defined by XSDs. Yes I'm disillusioned with the unnecessary re-invention of the wheel here. And "REST" interfaces defined with gigantic OpenAPI documents aren't really all that better than SOAP, just with hip and still-in-development toolchains around them. It's all marketing and popularity contests, and SOAP/XML/XSD lost out.
- abraae 6y ago> It's all marketing and popularity contests, and SOAP/XML/XSD lost out. I believe the triumph of REST over SOAP was mainly piggy-backed off of the triumph of JSON over XML (even though neither has technically anything to do with REST). In practice, in most people's minds, REST == JSON and SOAP == XML and JSON > XML. Therefore REST > SOAP. Though as you note, what most people today call REST falls way short of the whole singing and dancing HATEOAS bag that Roy had in mind. (Personally I think hypermedia is way overrated for most APIs, though that's not an opinion many REST zealots are open to).
- ratww 6y agoIt was both JSON and the "pretty" URLs, which also don't have anything specific to do with REST but people immediately associate them with it, to the point some people call them "RESTful URLs".
- slaymaker1907 6y agoI think JSON is an improvement over XML for RPC, though they are similar. Generic JSON serialization/deserialization is trivial for any language with arrays and string maps. With XML, are fields serialized as attributes or as tags? Unless you are doing something really weird, JSON tells you just to use a JSON object. And for lists: do you use a special <li /> like take for the items or do you skip the intermediate step and just assume each child item is a list? JSON is definitely not perfect and has similar problems with things like serializing maps with objects as keys, but it does have more opinionated ways for serializing things than XML does.
- ragnese 6y ago> As it is though, most people just don't know any other consistent, repeatable way to break a complex system down. I think MVC is that. It's just vague enough that you can square-peg-round-hole almost anything into it, but it's also pretty prescriptive in that there are exactly three "components" to your program and each has a specific role and relationship to the others.
- slaymaker1907 6y agoI think the flow architecture (i.e. Redux) is sufficiently descriptive for how to organize a project, at least compared to REST. There is one giant state object which is essentially a struct/trivially serializable to JSON. This state can only be changed via actions/events which are themselves only structs, not full objects. Reducer function(s) transform the old state into a new state using these events (in practice people use multiple reducer functions which are chained together). This isn't even message passing really since you do have global state, it's just that this global state is changed via messages/events.