Reputation: 15660
I'm trying to figure out what the latest best practice is when it comes to REST APIs and finding an elegant way to "tell" the client what the response will look like. I'm no web expert. But I just recently joined a new team and I've noticed that in the client code, they have hardcoded URI to APIs... and anytime the schema of the return data changes, they have to patch their client code.
Trying to find a way to make things more dynamic by:
More than anything else though, what I'm trying improve is having to change the client code each time the logic on the server changes as far as the body of a GET response.
I've been reading this: https://www.programmableweb.com/news/rest-api-design-put-type-content-type/2011/11/18
And in particular, the following comments stood out to me: (under the WRML heading)
this media type communicates, directly to clients, distinct and complementary bits of information regarding the content of a message. The Web Resource Modeling Language (WRML, www.wrml.org) provides this "pluggable" media type to give rich web applications direct access to structural information and format serialization code. The media type's self-descriptive and pluggable design reduces the need for information to be communicated out-of-band and then hard-coded by client developers
Questions
Or if you have any other suggestions I'm all ears.
Thank you.
Upvotes: 0
Views: 1051
Reputation: 99523
I don't know much about WRML, but I would look into:
I've been developing Ketting for the last 5 years and HATEOAS has been nothing short of magic lately as all the tools have been falling into place.
Upvotes: 1