Is http basic over ssl a realistic solution in most cases?
ROCA: Resource-oriented Client Architecture – an alternative to SPAs
21–25 of 25 posts
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#22I 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…
I’ve had this discussion as well, and I fully agree. In my experience, this kind of thing exists purely to sneak in the more programmer friendly JSON in corporate environments that have otherwise “standardized on XML”. You wouldn’t get away with pure JSON, but you can argue for a hybrid approach.
yes. and the version 1 just provides json. After a while, the client accept to forget about xml (in favour of other functionalities) and the case is closed.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#23Adding AJAX (and usability) to ROCA-style applications is exactly what intercooler as designed to do:
No application-land javascript code, just HTML-extending attributes that fill out the functionality missing in vanilla HTML.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#24Is http basic over ssl a realistic solution in most cases?
No, it’s not. That’s why we wrote “because of the limits of browser-native authentication (e.g. no logout, no styling), form-based authentication in conjunction with cookies can be used”. In practice, that’s the only option for public applications.
Re: ROCA: Resource-oriented Client Architecture – an alternative to SPAs
#25Is http basic over ssl a realistic solution in most cases?
No, it’s not. That’s why we wrote “because of the limits of browser-native authentication (e.g. no logout, no styling), form-based authentication in conjunction with cookies can be used”. In practice, that’s the only option for public applications.
I would question why that is first in the list then as it is confusing and at odds with the rest of the document which appears to aim for clarity.
Would something like this be better?
"Authenticated communication via a browser relies form-based authentication, possibly in conjunction with cookies. If cookies are used, they should include all of the state needed for the server to process them. All other forms of authenticated communication should rely on HTTP Basic or Digest Authentication, typically combined with SSL, possibly with client certificates."
Unless HTTP Basic / Digest are also unsuited for public API's in which case should they not be removed and some other recommendation be made?