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

Is REST Best in a Microservices Architecture?

capgemini.github.io

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Is REST Best in a Microservices Architecture?

#21

Post by mateuszf »

icebraining wrote: post #20

I think the problems identified with the architecture are being wrongly imputed on REST. REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead cre…

> the stock manager could offer a feed

How does it differ from polling?

Re: Is REST Best in a Microservices Architecture?

#22

Post by icebraining »

mateuszf wrote: post #21
icebraining wrote: post #20

I think the problems identified with the architecture are being wrongly imputed on REST. REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead cre…

> the stock manager could offer a feed How does it differ from polling?

It doesn't, it differs from polling each product, since it provides a single resource for all of them.

An alternative would be for the Inventory system to allow the Email system to register a callback URL (aka Webhook) with it that gets called when the stock updates - allowing for push events while maintaining a decoupled architecture -, but that is only useful if the stock only gets updated sporadically, as you should still have a resource that can be polled, in case the Email system dies and then needs to check what happened when it was offline.

Re: Is REST Best in a Microservices Architecture?

#24

Post by HappyTypist »

icebraining wrote: post #20

I think the problems identified with the architecture are being wrongly imputed on REST. REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead cre…

Polling a "show me all updates since X" endpoint is a reasonable approach that is loosely coupled and minimises the amount of transfer needed.

Re: Is REST Best in a Microservices Architecture?

#25

Post by eponeponepon »

The only real problem I find with REST+microservices as an architecture is situations where the right framework for one of the microservices' jobs is not well-equipped for HTTP interactions.

Although it's always possible to knock something up to get the job done, a developer working in (e.g.) XSLT is not necessarily in his or her comfort zone when working with remote services, and that tends to cause delays and other headaches.

Otherwise, though, I'm all in favour of it as an architectural choice.

Re: Is REST Best in a Microservices Architecture?

#26

Post by eponeponepon »

harry-wood wrote: post #14

From the headline I thought it was going to be trying to persuade us all that SOAP is better than REST. ...Phew! Turns out it's really "Is request-response the best Microservices architecture?"

SOAP really excited me when I did some training on it a while back - then, I read about REST.

Now, REST is all over my life, and I have literally never used SOAP since that training.

Re: Is REST Best in a Microservices Architecture?

#27

Post by edem »

icebraining wrote: post #20

I think the problems identified with the architecture are being wrongly imputed on REST. REST is synchronous in terms of request/reply, but that doesn't mean that higher-level actions must (or even should) be restricted to that cycle, so subprocesses like the notification should never have to block the stock update. Even if the requester needs to be informed about that, the stock updating mechanism should instead cre…

So you imply that the OP is defeating a straw man, right?

Re: Is REST Best in a Microservices Architecture?

#30

Post by spo81rty »

zkhalique wrote: post #8
bayesianhorse wrote: post #2

The obvious solution is probably the best: Use an asynchronous framework (like node.js or asyncio) for the REST interface and wait for the completion of the task to return a response. That process wouldn't handle all the details of the task, but it can wait for notification of the task via other means (celery, rabbitmq, redis, whatever...). Personally I think REST is the best paradigm for most microservices. There is…

How about batching stuff?

Yup. Batching is why we use queuing.
Post reply on HN