How is HATEOAS possible if markup doesn’t adequately support protocol transactions?

Regards,
Mike

Earlier on you speculated about why people find the HATEOS idea so difficult to follow. My view is it’s caused by the lack of good examples and/or a good book.

It might be worth contrasting it with DDD, in my view similiarly complex and also looking at designing simple software with a long term viewpoint.
As with anything DDD suffers from misunderstandings and people sometimes focus too much on the unimportant aspects.However overall things are in a much better state than they are with REST and I think that’s largely because Evans’ book really focusses the mind and describes real world examples that illustrate why his ideas are important. Similiarly the published code/design examples give people something to focus on.

However when it comes to REST a lot of content available on the Web, even from true REST experts, is quite unhelpful to newcomers. In fact *good* REST examples and discussions were thin on the ground until recently, probably fuelling the incessant squabbling and more recently the hijacking of REST (including WOA).

As I say recently we’ve had some realistic examples (I’m thinking in particular of http://www.infoq.com/articles/webber-rest-workflow, even though you might not consider it RESTful) but I certainly think that a lot more could be done and that perhaps a good book is in order?

Just my 2c as someone whose gradually coming to appreciate REST after many months of trying to get to grips with the great ideas behind it.

Thanks,

Colin

The first bullet says “REST API should not be dependent on any single communication protocol.” and “In general, any protocol element that uses a URI for identification must allow any URI scheme to be used for the sake of that identification.”

If I understand it correctly, when I design a media type, I should not restrict URIs to a limited set of URI schemes. However, HTML doesn’t define how user agents can handle a form tag which uses a URI other than an HTTP URI as the value of its action attribute. Then who can decide which method needs to be used with an FTP URI? It seems HTML restricts the possible values of form’s action attribute to only HTTP URIs. How could I explain this?

The HTML specification doesn’t say that user agent developers need to use HTTP’s GET method for an anchor. Then how could they know how to handle the element with HTTP?

I know my English is really bad, but I just want to know how I can define in the media type that an anchor needs to be handled with HTTP’s GET.

A distributed queue is an implementation choice. You can certainly implement some applications by having them interact with a queue-like resource in a RESTful manner. However, if your client relies on the resource being a queue, then it certainly isn’t a RESTful API. Do you see the difference? Encoding knowledge within clients and servers of the other side’s implementation mechanism is what we are trying to avoid.

If a client is receiving instructions on how to interact with a resource just before acting only on those instructions, then the client doesn’t care if the resource is a distributed queue. It simply doesn’t need to know how the resource is implemented. All it needs to know is the meaning of those instructions and some idea of what it wants to do next, whether that purpose be user-driven, configuration-driven, or some sort of AI-driven.

What about the usecase of a distributed queue? The queue should not care about the media types it is exchanging between senders and receivers, yet it can quite easily satisfy the addressability, uniform interface, and statelessness constraints of a RESTful architecture. Can’t a service that is media-type agnostic be a RESTful API? Such a service would require assigning semantic meaning to a specific HTTP method and URI pattern and would not receive state transition information from its exchanged media types (as the service doesn’t care or need to know about the media types). I hope I am explaining myself well.

For example:
POST /{queue-name} sends a message to the queue
GET /{queue-name}/top is the current message waiting to be processed. It returns
Location: /messages/111
DELETE /messages/111 tells server you are done processing that message.

There are specific state transitions for the receiver, but why does the media type have to contain information on how to process a received message?

Assigning a little bit of semantics to the URI and HTTP methods adds a lot of simplicity to the overall architecture without requiring an “envelope” format to exchange data. I also think it is far easier to maintain and re-use over the long term.

…

I am not sure why you think that having an obscure URI format will somehow give you a secure call (whatever that means). Identifiers are public information.

RESTful systems perform secure operations in the same way as any messaging protocol: either by encapsulating the message stream (SSL, TLS, SSH, IPsec, …) or by encrypting the messages (PGP, S/MIME, etc.). There are numerous examples of that in practice, and more in the future once browsers learn how to implement other authentication mechanisms.

do you think any of the public API’s out there are truly RESTful?

One problem I have is how to do security and keep it pure RESTFul

In order to have secure call I have to do something like:

GET /resource/11231231/token=KJGHY7687JKGH

Unless I do POST – is there a better way you see for this?

Dima.