An Hypermedia Engine - Case Study

87 views
Skip to first unread message

J Fernandes

unread,
May 12, 2016, 3:41:49 AM5/12/16
to hyperme...@googlegroups.com
Hi all,

I've recently published a brief case study covering a few Hypermedia practical patterns that have worked well for me in the past. 


Would be really keen to know if this relates to other peoples experiences, and also what other kind of practical patterns you found useful out there.

Looking forward,

J Fernandes

PS: cross post from #api-craft

mca

unread,
May 13, 2016, 1:41:46 AM5/13/16
to hyperme...@googlegroups.com
JF:

good to see this kind of work and thanks for sharing.

some quick comments here:

WHAT IS AN INTERFACE
"Integrating through interfaces is fragile"
Well, a TPC/IP Port where you send documents back and forth is an INTERFACE -- that's HTTP. so, i think you mean to say function-style interfaces (ones that require early-binding of function, arguments, and return types) is fragile.

INSTANT CHANGES
"The client is decoupled from the server"
This can mean the client and server can be modified independently. it doesn't REQUIRE the server to communicate changes instantly nor does it REQUIRE clients pay attention to those changes. in a well-implemented loosely-coupled network software implementation clients written ten years ago continue to work just fine (e.g. they haven't "instantly changed when the service changes"). the notion that clients MUST follow the servers as they change is not a good long-term strategy. of course, clients MAY adapt to changes at any time.

UX-ONLY?
"clients only need to be re-deployed for UX concerns"
in well-designed systems, clients MAY be deployed to solve a new problem the service providers never even though of at the time the service was created. we've all experienced this ("Hey, you mean you can read from there and there, do a small computation, and then write the results to here? Wow, i never realized you could use this app in that way!").  clients are not UX only. they have their own role to play and MAY be handling work the services know nothing about. this is esp. true when clients combine more than one service locally to create a new solution/solve a problem that no single service even knows about.

CLIENT OR SERVER?
I encourage you to think about clients and servers as peers in solving problems. consider that when an app makes a request it is playing the role of a "client" and when that same app sends a response to some other app, it is playing the role of a "service." this is essentially what middleware in a network software system does all the time. 

I look forward to seeing the repo grow over time.

cheers.

--
You received this message because you are subscribed to the Google Groups "Hypermedia Web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hypermedia-we...@googlegroups.com.
To post to this group, send email to hyperme...@googlegroups.com.
Visit this group at https://groups.google.com/group/hypermedia-web.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages