What does it mean to not use hypermedia?
90 views
Skip to first unread message
nickdu
Jan 3, 2016, 11:40:38 PM1/3/16
to Hypermedia Web
Sorry, couldn't think of a good wording for the title. Here's the question I have.
Let's say someone is going to author an API. They were thinking of making it RESTful but decided that they don't want to included hypermedia in the responses. Thus I guess you might call it a HTTP API or Web API. I'm wondering, what are the potential downsides from not being hypermedia driven?
HATEOAS would seem to indicate, based on it standing for "Hypermedia As The Engine Of Application State", that the application state is contained within the hypermedia, eg. links. Thus if the API is not going to include hypermedia it would seem to mean that the application state will not be driven by the server. Is that true? If so, does it mean the client is going to be maintaining the application state by having to know what the state is by what transitions have been made? It would seem problematic to have a client maintain the state of an application which is running on the server. This would seem to couple the client and server more tightly.
Thanks,
Nick
Let's say someone is going to author an API. They were thinking of making it RESTful but decided that they don't want to included hypermedia in the responses. Thus I guess you might call it a HTTP API or Web API. I'm wondering, what are the potential downsides from not being hypermedia driven?
HATEOAS would seem to indicate, based on it standing for "Hypermedia As The Engine Of Application State", that the application state is contained within the hypermedia, eg. links. Thus if the API is not going to include hypermedia it would seem to mean that the application state will not be driven by the server. Is that true? If so, does it mean the client is going to be maintaining the application state by having to know what the state is by what transitions have been made? It would seem problematic to have a client maintain the state of an application which is running on the server. This would seem to couple the client and server more tightly.
Thanks,
Nick
Ruben Verborgh
Jan 4, 2016, 4:06:30 AM1/4/16
to hyperme...@googlegroups.com
Hi Nick,
> I'm wondering, what are the potential downsides from not being hypermedia driven?
The contract between a client and a server is stronger then,
clients bind to specific identifiers instead of to a dialogue.
They also need to know the possible next steps beforehand
If APIs and clients are developed for the short term, as is the case today,
then there won't be much difference in reality. REST is all about the long term.
More info: Why is the Web Loosely Coupled? A Multi-Faceted Metric for Service Design
http://www2009.eprints.org/92/1/p911.pdf
> Thus if the API is not going to include hypermedia it would seem to mean that the application state will not be driven by the server.
Hypermedia does _not_ mean that application state is driven by the server.
Rather, it means that the information to manipulate the application state
is in the responses sent by the server, rather than hard-coded in the client.
> If so, does it mean the client is going to be maintaining the application state by having to know what the state is by what transitions have been made?
Or it could be the server maintaining the application state,
i.e., having a session per client.
Statelessness is orthogonal to hypermedia though:
you can do hypermedia with state
and statelessness without hypermedia
(but hypermedia can be used to drive the application state).
> It would seem problematic to have a client maintain the state of an application which is running on the server.
Your browser does it all the time ;-)
It would be even more problematic if the server kept the application state:
it would need space for all clients then, whereas each client only needs space for itself.
Best,
Ruben
> I'm wondering, what are the potential downsides from not being hypermedia driven?
clients bind to specific identifiers instead of to a dialogue.
They also need to know the possible next steps beforehand
If APIs and clients are developed for the short term, as is the case today,
then there won't be much difference in reality. REST is all about the long term.
More info: Why is the Web Loosely Coupled? A Multi-Faceted Metric for Service Design
http://www2009.eprints.org/92/1/p911.pdf
> Thus if the API is not going to include hypermedia it would seem to mean that the application state will not be driven by the server.
Rather, it means that the information to manipulate the application state
is in the responses sent by the server, rather than hard-coded in the client.
> If so, does it mean the client is going to be maintaining the application state by having to know what the state is by what transitions have been made?
i.e., having a session per client.
Statelessness is orthogonal to hypermedia though:
you can do hypermedia with state
and statelessness without hypermedia
(but hypermedia can be used to drive the application state).
> It would seem problematic to have a client maintain the state of an application which is running on the server.
It would be even more problematic if the server kept the application state:
it would need space for all clients then, whereas each client only needs space for itself.
Best,
Ruben
nickdu
Jan 4, 2016, 8:53:03 AM1/4/16
to Hypermedia Web
Hypermedia does _not_ mean that application state is driven by the server.
Rather, it means that the information to manipulate the application state
is in the responses sent by the server, rather than hard-coded in the client.
Not sure I agree about this. Yes, the client decides the "transition" to follow, but the state, which I guess is embedded in the links if the API is hypermedia is driven, would of course be managed by the server. I guess a reasonable example might be paging through a collection. If the API is hypermedia driven the server would know what page you're one and would give you transitions for "next", "prev", "search", etc. If the API is not hypermedia driven the client would have to keep track of what page they're on and generate the appropriate links for navigating between the pages.
clients bind to specific identifiers instead of to a dialogue.
What do you mean by 'dialogue'? Is that just another name for a link relation?
> It would seem problematic to have a client maintain the state of an application which is running on the server.
Your browser does it all the time ;-)
It would be even more problematic if the server kept the application state:
it would need space for all clients then, whereas each client only needs space for itself.
Maybe I didn't word this correctly. From my understanding, in a RESTful API, the server manages the state. It determines the possible transitions from a state. The client instructs the server on what transition to make and the server makes the state change. The state is then transferred to the client to hold onto. So by "maintaining" I don't mean simply holding onto the state. What I mean by that is that if you choose to not use hypermedia the client will have to determine the application state after each transition. This is not something the browser does. The browser will just hold onto the state.
Thanks,
Nick
Thanks,
Nick
Ruben Verborgh
Jan 4, 2016, 11:23:36 AM1/4/16
to hyperme...@googlegroups.com
Hi Nick,
>> Hypermedia does _not_ mean that application state is driven by the server.
>> Rather, it means that the information to manipulate the application state
>> is in the responses sent by the server, rather than hard-coded in the client.
>
> Not sure I agree about this. Yes, the client decides the "transition" to follow, but the state, which I guess is embedded in the links if the API is hypermedia is driven, would of course be managed by the server.
Depends on what you mean with "managed".
This term has different interpretations.
In one interpretation, "manage" could mean
that the server has to “keep track” of the application state.
For this interpretation, I disagree:
a REST server does not store application state.
In another interpretation "manage" could mean
that the server “decides” which state transitions are afforded.
For that interpretation, I agree.
> If the API is hypermedia driven the server would know what page you're on
The server does not (need to) know what page you are on;
it only knows what page you requested.
E.g., I request 37, which leads the server to send me
a hypermedia document that includes the link to page 38.
But as soon as the server has sent me this page,
it forgets what page the client is on.
It does not need to remember, because
the possible transitions are inside of the hypermedia document.
Therefore, the server does _not_ keep application state,
it only generates possible application state transitions.
> If the API is not hypermedia driven the client would have to keep track of what page they're on and generate the appropriate links for navigating between the pages.
Not necessarily. Another possibility is that the server
remembers on what page the client is,
and that the client sends a request "next page".
I.e., the server knows the client is on page 37,
the client sends a "next page" message,
so the server returns page 38.
You could even do this fully hypermedia-driven:
<a href="?next-page">next page</a>
This would be hypermedia but not REST,
exemplifying my statement that those are orthogonal.
> clients bind to specific identifiers instead of to a dialogue.
>
> What do you mean by 'dialogue'? Is that just another name for a link relation?
The dialogue consists of the messages exchanged by clients and servers.
A hypermedia document includes links (and link relations),
but there can be more inside of the response (data, metadata, controls).
> From my understanding, in a RESTful API, the server manages the state
That's incorrect, depending on the definition of "manages".
> It determines the possible transitions from a state. The client instructs the server on what transition to make and the server makes the state change.
Yes.
> The state is then transferred to the client to hold onto.
More precisely: the possible state transitions are transferred.
> if you choose to not use hypermedia the client will have to determine the application state after each transition.
This is not correct, as per my example above
in which the server keeps application state.
In non-REST scenarios, the client will typically be responsible
for generating its next message all by itself,
whereas hypermedia responses guide clients in generating messages.
This is the crucial difference.
Best,
Ruben
PS This discussion of application state versus resource state
might clear things up: http://ruben.verborgh.org/blog/2012/08/24/rest-wheres-my-state/
>> Hypermedia does _not_ mean that application state is driven by the server.
>> Rather, it means that the information to manipulate the application state
>> is in the responses sent by the server, rather than hard-coded in the client.
>
> Not sure I agree about this. Yes, the client decides the "transition" to follow, but the state, which I guess is embedded in the links if the API is hypermedia is driven, would of course be managed by the server.
This term has different interpretations.
In one interpretation, "manage" could mean
that the server has to “keep track” of the application state.
For this interpretation, I disagree:
a REST server does not store application state.
In another interpretation "manage" could mean
that the server “decides” which state transitions are afforded.
For that interpretation, I agree.
> If the API is hypermedia driven the server would know what page you're on
it only knows what page you requested.
E.g., I request 37, which leads the server to send me
a hypermedia document that includes the link to page 38.
But as soon as the server has sent me this page,
it forgets what page the client is on.
It does not need to remember, because
the possible transitions are inside of the hypermedia document.
Therefore, the server does _not_ keep application state,
it only generates possible application state transitions.
> If the API is not hypermedia driven the client would have to keep track of what page they're on and generate the appropriate links for navigating between the pages.
remembers on what page the client is,
and that the client sends a request "next page".
I.e., the server knows the client is on page 37,
the client sends a "next page" message,
so the server returns page 38.
You could even do this fully hypermedia-driven:
<a href="?next-page">next page</a>
This would be hypermedia but not REST,
exemplifying my statement that those are orthogonal.
> clients bind to specific identifiers instead of to a dialogue.
>
> What do you mean by 'dialogue'? Is that just another name for a link relation?
A hypermedia document includes links (and link relations),
but there can be more inside of the response (data, metadata, controls).
> From my understanding, in a RESTful API, the server manages the state
> It determines the possible transitions from a state. The client instructs the server on what transition to make and the server makes the state change.
> The state is then transferred to the client to hold onto.
> if you choose to not use hypermedia the client will have to determine the application state after each transition.
in which the server keeps application state.
In non-REST scenarios, the client will typically be responsible
for generating its next message all by itself,
whereas hypermedia responses guide clients in generating messages.
This is the crucial difference.
Best,
Ruben
PS This discussion of application state versus resource state
might clear things up: http://ruben.verborgh.org/blog/2012/08/24/rest-wheres-my-state/
nickdu
Jan 4, 2016, 1:48:05 PM1/4/16
to Hypermedia Web
Thanks. In some cases I think we're saying the same thing in slightly a different way. By the way, we have no plans for the server maintaining state. The only question is whether we make use of hypermedia in the payloads from the server or not. I'm trying to get a handle on what the difference will be between making use of hypermedia and not making use of hypermedia.
The server does not (need to) know what page you are on;
it only knows what page you requested.
E.g., I request 37, which leads the server to send me
a hypermedia document that includes the link to page 38.
But as soon as the server has sent me this page,
it forgets what page the client is on.
It does not need to remember, because
the possible transitions are inside of the hypermedia document.
Therefore, the server does _not_ keep application state,
it only generates possible application state transitions.
In order for the server to hand me back a response in which "next" would take me to page 8, it would need to know I was on page 7. The state is returned in the hypermedia of the response. For instance:
"next" : "http://acme.com/issuetracker/issues?offset=40&size=5"
While that is a transition, there is state embedded in it. In the non-hypermedia API case, we'd probably define the issues collection as "http://acme.com/issuetracker/issues" and document that query parameters can be specified to navigate through the collection. The client would then need to maintain state and "add" the state to the collection uri.
Thanks,
Nick
"next" : "http://acme.com/issuetracker/issues?offset=40&size=5"
While that is a transition, there is state embedded in it. In the non-hypermedia API case, we'd probably define the issues collection as "http://acme.com/issuetracker/issues" and document that query parameters can be specified to navigate through the collection. The client would then need to maintain state and "add" the state to the collection uri.
Thanks,
Nick
Erik Mogensen
Jan 4, 2016, 6:14:05 PM1/4/16
to hyperme...@googlegroups.com
After reading this exchange I think there is some confusion about the term "state" and possibly about the term "application" —
I tried putting some words down to try to explain how I see this, it ended up being a pull request to Mike's "Implementing REST" wiki.
On Mon, Jan 4, 2016 at 7:48 PM nickdu <nick.p...@gmail.com> wrote:
In order for the server to hand me back a response in which "next" would take me to page 8, it would need to know I was on page 7. The state is returned in the hypermedia of the response. For instance:
It is indeed "state embedded in the URI" — Think about it. Where did the client get this URI? The previous response from the server. A hypermedia control can be thought of as a way for a server to send messages to its future self.
The application state (what the user is looking at) includes subtle clues in the hypermedia controls to pass just enough state for the server to recognise where that particular browser happened to be. Typically (ideally?) such state resides in the URIs, but nowadays it's pretty popular to use local storage and client side code to "remember" more and more things.
While that is a transition, there is state embedded in it. In the non-hypermedia API case, we'd probably define the issues collection as "http://acme.com/issuetracker/issues" and document that query parameters can be specified to navigate through the collection. The client would then need to maintain state and "add" the state to the collection uri.
You do end up with tighter coupling, which has been mentioned. I might call it a RPC-like architecture. If you stick with hypermedia, exposing "next" and "previous" links, you can change from offset=40&count=5 based pagination to a pagenumber=7&count=5, or to perhaps even a cursor-based pagination, after=nc39su&count=5. If you choose an RPC-like architecture, you have to document these possibilities up-front if you want to change.
Note, however, that even if you make hypermedia responses and link your things together, any client can easily reverse engineer your &offset=40&count=5 and code to those instead, and *those clients* would be just as brittle as if you'd gone RPC from day one.
PS This discussion of application state versus resource state
might clear things up: http://ruben.verborgh.org/blog/2012/08/24/rest-wheres-my-state/
Reading this (very good read Ruben) and the TAG finding does challenge my view on HTTP responses being interpreted in a stateless fashion. Hmm. I guess that is an ideal to uphold, because even in the face of e.g. scalability not being hurt by the responses being stateless, visibility is hurt, possibly other -ilities too.
--
-mogsie-
Kevin Swiber
Jan 4, 2016, 7:44:18 PM1/4/16
to hyperme...@googlegroups.com
I've seen this topic come up many times over the last handful of years.
This word is confusing in a distributed system: application.
Is the "application" the entire system? Is it my view/input into the system? Or is it some other elusive component?
Reality: No one really knows, and it probably isn't worth debating anyway.
Since REST uses a client-server constraint, I tend to use the terms "client" and "server." Client refers to the software responsible for communicating with one or more servers. In this context, "client" is not the user interface. Server refers to the software receiving requests and serving responses over one or more communication channels. In this context, "server" is not the storage mechanism.
With semantics improved by a caching constraint, clients are able to maintain state That state is built from resource representations of previously-completed requests.
Servers have a responsibility of responding to requests for resources. They do so with representations. Those representations adhere to a structure defined by a media type.
Think of client state as a cursor. The ability to advance the cursor forward relies on the last-known representation received by the server. The hypermedia elements of the representation say "These options are available to advance your cursor. Choose wisely." Moving forward may have side effects. The client-server communication protocol may have options to inform the client whether or not side effects will take place (POST, PUT, DELETE, and PATCH in HTTP). If time is an element of state saved by the client, the cursor may be able to move backwards; this won't always result in using the client-server protocol (again, thanks to caching).
Using this as a baseline, let's revisit the question: What does it mean to have client-server communication without hypermedia?
Without hypermedia, the options for where to move the client state cursor are not present in the last-known representation received from the server. This information has to come from elsewhere, often out-of-band documentation. The hypermedia constraint has certain properties, benefits, and trade-offs... same as any other architectural constraint.
We talked about the properties of hypermedia. What are some of the benefits?
- Visibility: By examining a representation, a human or a machine can know which requests are available. From companies adopting hypermedia, I've heard QA teams love that they can view next steps when building up regression test suites. Some client developers love being able to step through the API as they wish, discovering features as they go. When building a UI, this can propagate to an end user experience.
- Independent evolvability: With hypermedia, a client makes subsequent requests given information provided in the representation. To put it in concrete terms, with HTTP, a server has the ability to change URL structure and methods (to some degree) for subsequent requests. Clients will keep working. Clients couple to identifiers in the representation. New server features come with new identifiers. Clients can adapt to changing server representations instead of releasing new versions to cope with breaking changes.
- Decouples implementation: Because of the benefits outlined above, client releases aren't required to move in lock-step with server releases.
And the trade-offs:
- Degrades efficiency: Your representations are bigger on the wire.
There are more trade-offs from a non-technical perspective:
- Esoteric and fragmented advice: It's difficult to come up to speed on all the benefits and implementation details. This is getting better over time.
- YAGNI bucket: "You Aren't Gonna Need It." Many people think they won't need the benefits listed above or that the barrier to entry is too high to invest today. Early on, the communities surrounding REST did a good job making it seem inaccessible to the masses. We are starting to change that, but the damage is done. Sometimes, the argument is "we change too rapidly and control all implementations." I'm one of the few people who sees hypermedia as being beneficial even in these scenarios, especially as our distributed systems grow bigger and bigger. Blue/green deployments are becoming necessary, meaning systems will run in between-states through the upgrade lifecycle. Hypermedia helps here.
Cheers,
Kevin
--
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.
Ruben Verborgh
Jan 5, 2016, 5:20:50 AM1/5/16
to hyperme...@googlegroups.com
Hi Nick,
>> The server does not (need to) know what page you are on;
>> it only knows what page you requested.
>> E.g., I request 37, which leads the server to send me
>> a hypermedia document that includes the link to page 38.
>> But as soon as the server has sent me this page,
>> it forgets what page the client is on.
>> It does not need to remember, because
>> the possible transitions are inside of the hypermedia document.
>> Therefore, the server does _not_ keep application state,
>> it only generates possible application state transitions.
>
> In order for the server to hand me back a response in which "next" would take me to page 8, it would need to know I was on page 7.
No, the server does not need to know on what page you _were_.
It needs to know you _requested_ page 7, but these are (importantly) different things.
Knowing on which page you were,
requires the server to keep track of that in _between_ requests.
Knowing what page you requested only requires the server to remember this
during the processing of that _single_ request.
> The state is returned in the hypermedia of the response. For instance:
>
> "next" : "http://acme.com/issuetracker/issues?offset=40&size=5"
Indeed. The application state transitions are then in the response.
> While that is a transition, there is state embedded in it.
The application state itself is present only implicitly.
If the response mentions
"self": "http://acme.com/issuetracker/issues?offset=35&size=5"
or
"currentPage": 7
then the application state is present explicitly.
Do you see the difference?
> In the non-hypermedia API case, we'd probably define the issues collection as "http://acme.com/issuetracker/issues" and document that query parameters can be specified to navigate through the collection.
If the state is not explicitly mentioned in the response,
then the client indeed needs to do this.
My purpose with the mails on this thread
is to show that there's more nuance to
"(non-)hypermedia means this for state".
Many of the dimensions are orthogonal,
as the examples above show.
It is not because you don't use hypermedia
that the client _has_ to keep state,
and its not because you do use hypermedia
that the server does _not_ have to keep state.
Different combinations are possible,
and some are better than others for certain systems.
Best,
Ruben
>> The server does not (need to) know what page you are on;
>> it only knows what page you requested.
>> E.g., I request 37, which leads the server to send me
>> a hypermedia document that includes the link to page 38.
>> But as soon as the server has sent me this page,
>> it forgets what page the client is on.
>> It does not need to remember, because
>> the possible transitions are inside of the hypermedia document.
>> Therefore, the server does _not_ keep application state,
>> it only generates possible application state transitions.
>
> In order for the server to hand me back a response in which "next" would take me to page 8, it would need to know I was on page 7.
It needs to know you _requested_ page 7, but these are (importantly) different things.
Knowing on which page you were,
requires the server to keep track of that in _between_ requests.
Knowing what page you requested only requires the server to remember this
during the processing of that _single_ request.
> The state is returned in the hypermedia of the response. For instance:
>
> "next" : "http://acme.com/issuetracker/issues?offset=40&size=5"
> While that is a transition, there is state embedded in it.
If the response mentions
"self": "http://acme.com/issuetracker/issues?offset=35&size=5"
or
"currentPage": 7
then the application state is present explicitly.
Do you see the difference?
> In the non-hypermedia API case, we'd probably define the issues collection as "http://acme.com/issuetracker/issues" and document that query parameters can be specified to navigate through the collection.
then the client indeed needs to do this.
My purpose with the mails on this thread
is to show that there's more nuance to
"(non-)hypermedia means this for state".
Many of the dimensions are orthogonal,
as the examples above show.
It is not because you don't use hypermedia
that the client _has_ to keep state,
and its not because you do use hypermedia
that the server does _not_ have to keep state.
Different combinations are possible,
and some are better than others for certain systems.
Best,
Ruben
nickdu
Jan 5, 2016, 10:35:04 AM1/5/16
to Hypermedia Web
I still think we're talking the same thing but in different words. For instance, when I say the server needs to know what page I'm on in order to provide the correct next, I don't mean that the server is keeping my state "in between" requests. I mean that when I request page 7 the server has to determine the "current" state from the request I sent it in order to know that the "next" page is 8.
If the response mentions
"self": "http://acme.com/issuetracker/issues?offset=35&size=5"
or
"currentPage": 7
then the application state is present explicitly.
Do you see the difference?
Not sure. So "next" : "http://acme.com/issuetracker/issues?offset=40&size=5" is implicit but "self" is explicit?
My purpose with the mails on this thread
is to show that there's more nuance to
"(non-)hypermedia means this for state".
Many of the dimensions are orthogonal,
as the examples above show.
It is not because you don't use hypermedia
that the client _has_ to keep state,
and its not because you do use hypermedia
that the server does _not_ have to keep state.
Different combinations are possible,
and some are better than others for certain systems.
If we're not planning to maintain state on the server, then I assume not using hypermedia does mean the client will have to "maintain" the state. Is that true?
Thanks,
Nick
Thanks,
Nick
Ruben Verborgh
Jan 6, 2016, 5:33:02 AM1/6/16
to hyperme...@googlegroups.com
Hi Nick,
> I still think we're talking the same thing but in different words.
We probably mean the same,
but the choice of words is important here,
as subtle wording differences describe vastly different systems.
> I say the server needs to know what page I'm on
No, the server does not need to know,
because you explicitly tell the server what page you want.
E.g., if you request
/resources?page=7
then the server does not need to _know_ you're on page 7
because the clients sends a request that contains this information (for the server).
In another example, if a client requests
/resources?action=nextpage
then the server _does_ need to know what page the client is on.
This is why the wording is very important.
>> If the response mentions
>> "self": "http://acme.com/issuetracker/issues?offset=35&size=5"
>> or
>> "currentPage": 7
>> then the application state is present explicitly.
>>
>> Do you see the difference?
>
> Not sure. So "next" : "http://acme.com/issuetracker/issues?offset=40&size=5" is implicit but "self" is explicit?
With the "next" link, the information is:
"this is how you can reach the next page"
With the "self" link, the information is:
"you are currently no this page"
In simple books, one bit of information can be derived from another.
E.g., if I can reach the next page by going to page 8,
I know that I am currently on page 7.
In complex books (and more generic hypermedia interfaces),
this is not always clear.
E.g., the next page might be A1 (first page of the appendix),
but that does not tell me on what page I'm currently.
Or to give a hypermedia example:
next: "/payment?option=buyfullbook"
currentPage: 7
In order to go to the next page,
I first need to buy the entire book.
However, I am currently on page 7.
Note how none of either bits of information
allows to derive the other.
> If we're not planning to maintain state on the server, then I assume not using hypermedia does mean the client will have to "maintain" the state. Is that true?
Or the state can also be in the response.
For example
currentPage: 7
would be a response with application state,
but not hypermedia.
Best,
Ruben
> I still think we're talking the same thing but in different words.
but the choice of words is important here,
as subtle wording differences describe vastly different systems.
> I say the server needs to know what page I'm on
because you explicitly tell the server what page you want.
E.g., if you request
/resources?page=7
then the server does not need to _know_ you're on page 7
because the clients sends a request that contains this information (for the server).
In another example, if a client requests
/resources?action=nextpage
then the server _does_ need to know what page the client is on.
This is why the wording is very important.
>> If the response mentions
>> "self": "http://acme.com/issuetracker/issues?offset=35&size=5"
>> or
>> "currentPage": 7
>> then the application state is present explicitly.
>>
>> Do you see the difference?
>
> Not sure. So "next" : "http://acme.com/issuetracker/issues?offset=40&size=5" is implicit but "self" is explicit?
"this is how you can reach the next page"
With the "self" link, the information is:
"you are currently no this page"
In simple books, one bit of information can be derived from another.
E.g., if I can reach the next page by going to page 8,
I know that I am currently on page 7.
In complex books (and more generic hypermedia interfaces),
this is not always clear.
E.g., the next page might be A1 (first page of the appendix),
but that does not tell me on what page I'm currently.
Or to give a hypermedia example:
next: "/payment?option=buyfullbook"
currentPage: 7
In order to go to the next page,
I first need to buy the entire book.
However, I am currently on page 7.
Note how none of either bits of information
allows to derive the other.
> If we're not planning to maintain state on the server, then I assume not using hypermedia does mean the client will have to "maintain" the state. Is that true?
For example
currentPage: 7
would be a response with application state,
but not hypermedia.
Best,
Ruben
Reply all
Reply to author
Forward
0 new messages