ROCA: Resource-oriented Client Architecture – an alternative to SPAs
1–10 of 25 posts
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#2Reading through the site feels like a breath of fresh air in today's convoluted web development. This is how it should have been right from the beginning.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#3A thread from 2010: https://news.ycombinator.com/item?id=3672436
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#4Reading this was lovely. I strive for the majority of these goals. Unless it's an incredibly simple "one-task" sorta deal I avoid the SPA approach like the plague.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#5I don’t think a server should serve the same content in xml and json.
1. Why cater to this preference - you must ultimately force the consumer to do certain things to consume your data. Where do you stop? If some prefer the data in excel97 should you cater to that as well?
2. Do you want to have the liability of the possibility of the format’s data not being fully synchronized? Serve it one way and it will not happen.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#6I don’t think a server should serve the same content in xml and json. 1. Why cater to this preference - you must ultimately force the consumer to do certain things to consume your data. Where do you stop? If some prefer the data in excel97 should you cater to that as well? 2. Do you want to have the liability of the possibility of the format’s data not being fully synchronized? Serve it one way and it will not happen…
Virtually every editor, programming language, database system, etc., can deal with json and/or xml. So it's not much of a constraint. And there's nothing stopping you from providing additional streams if they're desired for any reason.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#7I don’t think a server should serve the same content in xml and json. 1. Why cater to this preference - you must ultimately force the consumer to do certain things to consume your data. Where do you stop? If some prefer the data in excel97 should you cater to that as well? 2. Do you want to have the liability of the possibility of the format’s data not being fully synchronized? Serve it one way and it will not happen…
Most of our REST endpoints can generate HTML, JSON and some of them text/csv. It's been working really well for us since 2016.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#8This seems a very nostalgic take.
So long as websites pretend they are documents, they will remain bloated poorly performing synchronous applications.
Accept that websites are distributed applications and deliver great experiences.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#9This strikes me more as a set of gripes (to be sure, valid and reasonable gripes). Not an architecture exactly
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#10I don’t think a server should serve the same content in xml and json. 1. Why cater to this preference - you must ultimately force the consumer to do certain things to consume your data. Where do you stop? If some prefer the data in excel97 should you cater to that as well? 2. Do you want to have the liability of the possibility of the format’s data not being fully synchronized? Serve it one way and it will not happen…
[deleted]