Hacker News Reader

Comment by pikzen | Hacker News Reader

We've already established REST has crippling limitations. Introducing RPC in it makes up for those.

You can also make it a long lived connection, that waits for a proper confirmation, which means you might be waiting ten seconds. Or you can make it a fire-and-forget operation, and have a resource to check if it was properly sent. Which is back to polling. Or you can use server-sent events to have the server notify you back when it's done.

But yes, unless you explicitly need to be able to send emails from clientside, I wouldn't expose a sendmail resource, and would leave that to the server. (I say as I recently implemented a resource that allows me to post an event from client side to allow the server to send it back. :| )

Ultimately, do what works. The pure REST cargo cult is dangerous. As long as what you do is clean, maintainable and ideally idempotent, you're good.

View on HN

We've already established REST has crippling limitations.

No, we haven't. I explicitly disagreed with that assertion. REST is not adequate for everything, but it doesn't have "crippling limitations". It's pretty good for its intended use.

You can also make it a long lived connection, that waits for a proper confirmation, which means you might be waiting ten seconds.

You can't rely on the connection lasting that long. REST's design was a major sucess on the Internet in part because it naturally dealt with the connectivity limitations.

Or you can make it a fire-and-forget operation, and have a resource to check if it was properly sent.

Yes. That's what REST means. That's my point!

Or you can use server-sent events to have the server notify you back when it's done.

You still have to create an unique ID for the operation, so that the client can tell what is done. Having an URL as that ID is barely any effort.

Ultimately, do what works. The pure REST cargo cult is dangerous. As long as what you do is clean, maintainable and ideally idempotent, you're good.

There's nothing clean and maintainable about having ad-hoc mechanisms that break the overall functioning of the API. If you're using a paradigm, be that REST, RPC, or anything else, you should have a major reason to break it.

... Then make an endpoint where you can get a task's status through its ID (your post to sendmail would then return a task ID), and poll repeatedly until it's marked as done, wasting bandwidth, your architecture, your choices ¯\_(ツ)_/¯

Or you can let the server notify you when it's done, and carry on with your work. As a bonus, most clients able to receive SSE already include automatic reconnection to the feed if it ever gets cut.

They're not incompatible, though. I'd make everything as a REST endpoint (since you need to create a resource with an ID anyway for SSE, otherwise, how will the client know which email want sent?), and then add SSE as an optional performance improvement layer on top of those endpoints that may benefit from it.

This is how WebSub (formely PubSubHubbub) works on top of RSS/Atom, for example.

Reply on news.ycombinator.com