hypermedia

I've been reading up on 'real' RESTful APIs for a few days now, and I think I'm near to groking what it's about. But one of the things that I stumble on is that I can't even begin to imagine how one would write a client for a 'real' hypermedia API: Most of the examples I've read talk about browsers and spiders, but that's not especially helpful: one is human-directed and 'intelligent', the other is dumb and 'random'. As it stands, I kind of get the impression that you'd need to learn AI to get a client working. One thing that isn't clear to me is how the client knows which verb to use on any

I am in the early stages of planning a REST api, and I would like for it to adhere to the HATEOAS constraint of REST. But I would also like to provide a JSON format. So my question is if there are conventions out there to represent links and forms in JSON. I have found examples of links, and it looks like this is a pretty common way of representing links: "links": [ {"rel": "self", "href":"http://example.org/entity/1"}, {"rel": "friends", "href":"http://example.org/entity/1/friends"}] Representing forms on the other hand, is not something that I have seen much of. I was thinking that perhaps

I'm currently reading "Rest in practice" book . I'm unable to understand the following terminology Hypermedia , hypermedia format, hypermedia controls, Domain application protocol. The author was suggesting need for domain specific hypermedia format. I could hardly understand those. I googled these terms but couldnt find a right answer. Can anyone explain these terminologies and why we need domain specific hypermedia formats instead of application/xml ? Hypermedia = the fact that client and server are talking in terms of some a uniform representation eg: hyper links. HyperMedia Control = A

I'm playing with REST right now and thought I properly implement HATEOAS just to get all concepts right. For that I want to create my own media types ( application/vnd[...]+xml and application/vnd[...]+json ). One first question: Does the media type define the contract between my server and client? The media type will define my message formats so I need to add XML schema and JSON schema to go with the new media types (so that REST clients know what's coming in messages and what to send back). I've done some research on the web but the details of how one does this are missing. Does it only

According to the HAL standard (see here and here ) the links to other resources should be placed in a specific embedded section. So for instance this is not valid HAL, is my understanding correct? { "movies": [ { "id": "123", "title": "Movie title 1", "_links": { "subtitles": { "href": "/movies/123/subtitles" } } },{ "id": "456", "title": "Movie title 2", "_links": { "subtitles": { "href": "/movies/456/subtitles" } } } ], "_links": { "self": { "href": "/movies" } } } The reason for which the above JSON is not valid HAL is that the links should be placed in an embedded section ( "_embedded" )

What is the standard pattern of orchestrating microservices? If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it? Let's say we have something like this: Invoicing Shipment And for the sake of the argument, let's say that once an an order has been shipped, the invoice should be created. Somewhere, someone presses a button in a GUI, "I'm done, let's do this!" In a classic monolith service architecture, I'd say that there is either an ESB handling this, or the Shipment service