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

41–50 of 51 posts

Re: Is REST Best in a Microservices Architecture?

#41

Post by gmtgmt »

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…

It looks like ESB implementations from a decade back is being reasoned out into REST, like fitting a round peg in a square hole in many places in their diagrams

Re: Is REST Best in a Microservices Architecture?

#42

Post by NathanKP »

lsaferite wrote: post #37
NathanKP wrote: post #33

REST is not the source of the problem being described in the article. The problem in the article is from bad application of REST. I'm currently working at a startup that has about 15 microservices and there are a few different strategies that we use to solve the problems being described in this article: We do use HTTP REST style requests when one service needs to fetch data from another service on the fly (usually in…

I might suggest that 202 is a better response in your example.

Good point! The fact that there is a 202 status code also goes to show that REST best practices allows for both synchronous and asynchronous use cases.

Re: Is REST Best in a Microservices Architecture?

#43

Post by eternalban »

gmtgmt wrote: post #41
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…

It looks like ESB implementations from a decade back is being reasoned out into REST, like fitting a round peg in a square hole in many places in their diagrams

And finally reduced to TX monitor. Rinse and repeat.

Re: Is REST Best in a Microservices Architecture?

#44

Post by deadowl »

This article doesn't seem to be representative of its title. If you're going to ask that question, you have to make comparisons. I would probably say no, because until most of the web supports HTTP/2.0, there's no server-push capability which makes a lot of things a pain in the ass.

Re: Is REST Best in a Microservices Architecture?

#45

Post by grahar64 »

My company (Loyalty New Zealand) just open sourced some parts of our "Pipeline" implementation. The Alchemy Framework https://github.com/LoyaltyNZ/alchemy-ether and https://github.com/LoyaltyNZ/alchemy-resource were implemented to by us to make a reliable scalable, based on AMQP (e.g. RabbitMQ). It has been in production for about a year but are still refining some parts.

Re: Is REST Best in a Microservices Architecture?

#47

Post by Mandatum »

Admittedly too many API's written with a RESTful interface are designed in such a way that async calls and callbacks aren't being taken advantage of, I think the only real thing REST misses out on, is what tech like RabbitMQ provide.

And I'm OK with those being separated - to me, the more choice I have around techs used provides more competition for cleaner, easier configuration of said tech.

Re: Is REST Best in a Microservices Architecture?

#50

Post by lsaferite »

NathanKP wrote: post #42
lsaferite wrote: post #37

Earlier quoted context omitted.

I might suggest that 202 is a better response in your example.

Good point! The fact that there is a 202 status code also goes to show that REST best practices allows for both synchronous and asynchronous use cases.

Oh, I 100% agree. I'm using a RESTish API right now to do things that are VERY async. There's no way you'd want to block a response while a VM was fired up and provisioned.
Post reply on HN