Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

REST is the new SOAP

medium.com

Post reply on HN
Print view View original

301–310 of 351 posts

Re: REST is the new SOAP

#301

Post by jstimpfle »

olavk wrote: post #298
jstimpfle wrote: post #296

Earlier quoted context omitted.

Yes. Well, the exception perhaps being that its object-verb syntax supports function name completion in IDEs better. But I think it's a net negative, since it has more negative effects on architecture (wrong structure, because developers are encouraged to invent vague concepts to be home to methods that do less and less. It leads to endless bikeshedding). Not to speak of other bad ideas that once defined what OOP was…

And you have never seen an OOP project succeed?

I've seen quite a few good projects written in an "OOP" language, but not in an OOP style - mostly misuse classes for namespacing (which I don't think is a good idea either since it makes usages of namespaced things hard to find).

I've never seen a "true" OOP project that wasn't quite a mess and couldn't have been written much cleaner in a plain old procedural style:

Use freestanding functions, the most successful abstraction to date.

Stop with that singleton bullshit. Most things that need to be managed exist precisely once in a program (talk to the sound card, to the printer, to the network, to the graphics card, to the file system, allocate memory...). Making classes first and instanciating once (or how many times, how can I know by looking at that handle?) is just plain silly, overly verbose, and confusing to the consumer of the API.

Don't couple allocation and initialization. It's a stupid idea. It leads to pointless, inefficient, and (in some languages) error-prone one-by-one allocations.

Flat fixed structs for data organization. By default expose struct size for massive decrease in memory allocation. Expose almost all fields (except for truly platform / implementation-defined ones) and stop with that silly getter/setter boilerplate.

Mostly use data tables (with direct integer indexing mostly) like in a relational database, for data-driven architectures. (CS/programming technology TODO: How can we switch between AOS/SOA more seamlessly? Maybe we can get inspiration from Graphics APIs?)

Don't use silly flexible-schema XML/object hierarchies to "compensate" for having no idea what's in the data. It doesn't help.

Make interfaces ("vtables" if you will) only sometimes where they are needed, not by default. Don't call this inheritance. Bullshit. It's an interface, not more, not less. If you think interface descriptions must typically be bundled with each data item, think harder. They are independent data.

We don't need no friggin "doer" objects for every simple thing. It doesn't help a bit, but only makes things less readable and more complex. Just do what needs to be done!

Re: REST is the new SOAP

#302

Post by chiefalchemist »

bbarn wrote: post #13

Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case. Wha…

> "Everyone seems to want to find a reason to dislike product/technology/feature X..."

Furthermore, and it's been this way for as long as I can remember, too many want a tool to be the perfect fit for every problem.

That is, they pick up a screwdriver and then are shocked that it's not good for driving nails.

There is no OSFA technology.

Re: REST is the new SOAP

#303

Post by dsego »

snarfy wrote: post #98
speedplane wrote: post #91

Earlier quoted context omitted.

I actually agree with your sentiment, but disagree with your characterization that it's "laziness"... how about not knowing?

You're right, that's most likely the main offender. Apologies. I've been consuming a lot of poorly written REST apis lately and am bitter.

The worst one I worked with recently would return 200 and only a human readable error message (no status). On top of that the message is sometimes phrased differently. Here is an example from memory: "The field email is not valid." and "You provided an invalid username."

Re: REST is the new SOAP

#304

Post by dsego »

qznc wrote: post #291
jstimpfle wrote: post #266

Earlier quoted context omitted.

Now why does everybody mean different things by "REST"? Maybe because the idea "REpresentational State Transfer" was never that clear from the start. So that's some common ground. It's a bad idea.

It is hard to evaluate an idea without being tied to an implementation. How would you evaluate Monads as an idea without talking about Haskell? The primary problem with REST is that most people learn it by example. Then they believe it is about web services returning JSON or about pretty URLs. It is not.

I hate working with pedantic programmers who chastise you for using the wrong http method or not formatting url's correctly because it's not restful, and then few years later jump onto some new tech, like graphql or something else, and then evangelizing the new religion. That's how some "senior" devs maintain their importance, using this esoteric knowledge to keep lesser programmers out. And if you try to catch up, you're playing a fool's game, by the time you learn all the peculiarities of their interpretation of "RESTfull", they have already jumped to GraphQL. Same for React (remember this one - presentation (HTML) and logic (JS) should not mix!?), but now that we've switched from backbone to react, suddenly it's ok. It also applied to random methodologies like agile, scrum etc. A lot of cargo-culting, and not a lot of actual engineering.

Re: REST is the new SOAP

#305

Post by todd8 »

garganzol wrote: post #80

CORBA is the best protocol I ever dealt with. Strong contractual semantics, exceptions, interface definitions. Spiced with transparent compression, encryption and bi-directional communication. All those goodies were already available 12 years ago. The only downside - it required a reliable and precise implementation that took a lot of efforts. I always used IIOP.NET for most of my gigs and it was excellent. I also en…

I was somewhat involved with CORBA in its early days. It had some very smart people driving it. It was derived from work already being done by the large companies like IBM, DEC, Apollo, Sun, HP, and Microsoft.

But CORBA was haunted by a key principle that limited its influence. Unlike the IP protocol stacks, which are layered from the lowest wire protocols on up to the highest layers, CORBA dictated the highest level protocols and didn't address the lower level protocols. Different CORBA implementations couldn't talk to each other; consequently, CORBA didn't work for my company because we were was trying to design a product that could work across heterogeneous networks of workstations and servers.

If the CORBA folks were so smart (and they were), how could this happen? Why didn't they design the original CORBA protocols from say UDP or TCP on up? The CORBA members were all from different companies, and all had different independent products. There was fierce competition in this space so it was impossible for the members of CORBA to agree on the low level networking protocols because doing so would harm some companies' product lines while benefiting an others.

Re: REST is the new SOAP

#306

Post by jstimpfle »

Yokohiii wrote: post #102
speedplane wrote: post #24

Lots of comments here arguing REST is popular because it's easy, but there's another higher level reason too: it forces you to think about the network. In far too many RPC protocols, calling functions that operate over a network are treated like normal functions. A function call, almost by definition, fails to take into account network errors, and race conditions where multiple events overlap. Network calls are not f…

If a network (or endpoint) fails you usually only few options during runtime, retry, skip, stop. That is pretty much all you want to know. Everything else is specific to the endpoint, which is more about contracts and constraints then about networking. You either use the endpoint correctly of not. I.e. using a database like MySQL has similar constraints. And decent engineers know how to work with it and where it is h…

Yep, and no amount of REST / other introspective boilerplate can help about the fundamental problem of not being synchronized.

There is no solution to the "A knows X, but B does not know that A knows X, or A does not know that B knows that A knows X, or B does not know that A knows that B knows that A knows X..." problem.

Other than that, I think at some level networking is nothing more than function calls that can take a long time and/or fail.

Re: REST is the new SOAP

#307

Post by camus2 »

acjohnson55 wrote: post #190

I agree with the article. Fortunately, REST is dead. I'm fully confident that in 5 years, newcomers to web development will simply learn GraphQL. I realize that's a strident statement, but I really believe that. It is basically a restrictive implementation of RPC, which captures the reality that clients often need to ask for follow up data based on the result of a query. There are a couple needs that don't have fully…

> newcomers to web development will simply learn GraphQL.

I doubt it. Newcomers are supposed to learn HTTP. When one knows HTTP, one mostly knows REST.

GraphQL is not a replacement for REST, it's a query language on top of REST. It's a useful tool to fetch object graphs but REST is not going away anytime soon. GraphQL doesn't deal with security, caching and other issues solved with REST for instance. GraphQL also pushes a lot of complexity toward both the server and the client. On the server,it's an ORM on top of whatever ORM developers are already using.

Re: REST is the new SOAP

#308

Post by badsectoracula »

speedplane wrote: post #36
magic_quotes wrote: post #32

Earlier quoted context omitted.

The proper REST API should be specified as the set of domain-specific document formats (media-types) and have a custom browser as a client. Turns out, we already have HTML and web-browsers, so there is little point in actually building such APIs. It's always more appropriate to build a website instead. On other hand, what usually called 'REST' is nothing else but RPC where 'procedure call' = 'http method + url'. Ther…

Don't agree at all. There is a huge difference between calling a function "foo()" that makes an RPC call and the relatively equivalent REST call "http.GET('/foo')". The former feels like a function call, and callers will assume it operates like one. However, in reality the former is not a function, it's making a network call, and it's incredibly unreliable. In theory, the latter does the same thing, but it's far more…

How is that different than any function call that start something in the background? I have used and even written myself simple job code (with threading) that has functions like (simplified):

    int start(void (*job)(void*), void (*done)(void*), void* tag);
`job` is called on a separate thread at some point (goes through a job scheduler) and once it is done, `done` is called at the "main" thread (at some synchronization point, usually during the event loop), `tag` is just passed around for context. `start` returns zero on failure.

I don't see RPCs as anything different conceptually (after all the job might also fail). The only issue someone might have is when expecting a synchronous API, but even in non-networked code there are tons of asynchronous APIs.

Re: REST is the new SOAP

#309

Post by criddell »

niftich wrote: post #275
sopooneo wrote: post #274

Earlier quoted context omitted.

Thank you. This is one that I've been puzzling over for years. If anyone has a straightforward answer, and can provide example REST responses with and without "HATEOAS", I'd really appreciate it.

See the 'Richardson Maturity Model' levels [1], and contrast level 2 with 3. Level 3, satisfying the HATEOAS constraint, has hyperlinks leading to other resources, and the relationship between the origin and destination resource is qualified (with link relations [2]). Essentially, everything is a graph, resources are the nodes, and the labels on edges are the relations, also serving as an inventory of state transitio…

I think the problem I have a hard time with HATEOAS is that I really can't see what difference it makes to the API. I mean I get that it's always better to return a URI rather than simply an ID. But the link relations feel like they are from a time when we all thought the semantic web (RDF and OWL) was going to be a very big deal.

Re: REST is the new SOAP

#310

Post by rurounijones »

cm2187 wrote: post #62
lfischer wrote: post #59

Maybe REST was the best protocol for the great public API explosion of the past decade, where startups wanted to expose a public API to anyone on the internet. The most important requisite was that the most developers could access the API with a minimum of technical knowledge and tools, and the APIs were simple. I am less and less sure that REST is the best solution for communicating between internal services, which…

What do you think is a better solution?

https://grpc.io/ is Google's internal solution I believe
Post reply on HN