apiclientrestserver
I'm reading articles about REST including a tutorial. I've seen this site http://www.vogella.com/tutorials/REST/article.html, and there is a part for explaining the rest as:
In a REST based architecture, you have a REST server which provides access to the resources. A REST client can access and modify the REST resources.
Now I've searched what is the meaning of REST server and REST client but I could not find a good answer. Could someone explain them?
Edited to address question updates, previous answer removed
Looking over your changes to your question I think I understand the problem you are facing a bit more. As there is no field that is an identifier on your resources (just a link) you have no way to refer to that specific resource within your GUI (i.e. a link to a page describing a specific pet).
The first thing to determine is if a pet ever makes sense without an owner. If we can have a pet without any owner then I would say we need some sort of unique property on the pet that we can use to refer to it. I do not believe this would violate not exposing the ID directly as the actual resource ID would still be tucked away in a link that the REST client wouldn't parse. With that in mind our pet resource may look like:
<Entity type="Pet">
<Link rel="self" href="http://example.com/pets/1" />
<Link rel="owner" href="http://example.com/people/1" />
<UniqueName>Spot</UniqueName>
</Entity>
We can now update the name of that pet from Spot to Fido without having to mess with any actually resource IDs throughout the application. Likewise we can refer to that pet in our GUI with something like:
If the pet does not make any sense without an owner (or pets are not allowed in the system without an owner) then we can use the owner as part of the "identity" of the pet in the system:
http://example.com/GUI/owners/John/pets/1 (first pet in the list for John)
One small note, if both Pets and People can exist separate of each-other I would not make the entry point for the API the "People" resource. Instead I would create a more generic resource that would contain a link to People and Pets. It could return a resource that looks like:
<Entity type="ResourceList">
<Link rel="people" href="http://example.com/api/people" />
<Link rel="pets" href="http://example.com/api/pets" />
</Entity>
So by only knowing the first entry point into the API and not processing any of the URLs to figure out system identifiers we can do something like this:
User logs into the application. The REST client accesses the entire list of people resources available which may look like:
<Entity type="Person">
<Link rel="self" href="http://example.com/api/people/1" />
<Pets>
<Link rel="pet" href="http://example.com/api/pets/1" />
<Link rel="pet" href="http://example.com/api/pets/2" />
</Pets>
<UniqueName>John</UniqueName>
</Entity>
<Entity type="Person">
<Link rel="self" href="http://example.com/api/people/2" />
<Pets>
<Link rel="pet" href="http://example.com/api/pets/3" />
</Pets>
<UniqueName>Jane</UniqueName>
</Entity>
The GUI would loop through each resource and print out a list item for each person using the UniqueName as the "id":
<a href="http://example.com/gui/people/1">John</a>
<a href="http://example.com/gui/people/2">Jane</a>
While doing this it could also process each link that it finds with a rel of "pet" and get the pet resource such as:
<Entity type="Pet">
<Link rel="self" href="http://example.com/api/pets/1" />
<Link rel="owner" href="http://example.com/api/people/1" />
<UniqueName>Spot</UniqueName>
</Entity>
Using this it can print a link such as:
<!-- Assumes that a pet can exist without an owner -->
<a href="http://example.com/gui/pets/Spot">Spot</a>
or
<!-- Assumes that a pet MUST have an owner -->
<a href="http://example.com/gui/people/John/pets/Spot">Spot</a>
If we go with the first link and assume that our entry resource has a link with a relation of "pets" the control flow would go something like this in the GUI:
Using the second link would be a similar chain of events with the exception being that People is the entry point to the API and we would first get a list of all people in the system, find the one that matches, then find all pets that belong to that person (using the rel tag again) and find the one that is named Spot so we can display the specific information related to it.
Quit thinking in terms of MVC. MVC alone only describes the interactions well if everything happens on the server-side. You need to think at a higher level of abstraction. For example, Data Layer (ex database), API layer (ex server-side), Client Layer (Webapp, IOS app, Android App).
A basic SPA works on the premise that the whole site runs on one big HTML file. Reloads don't require a round-trip to the server because you're basically showing/hiding different sections of code.
In practice that's not necessarily true because the framework (ex Angular) can pull template partials and data from URLs in the background. It sounds like you understand this much but can't figure out how concerns should be separated between server/client.
For templating, do it the same as you would in Django. Except, instead of loading the files from a local directory you fetch the partials from the server.
For generating views that include data you'll need to make a controller that can fetch the data and use it in the view partial. There are many ways to go about this but the most common is to simply create an API on the server-side that accepts data requests and responds with the results in JSON.
In MVC terms. The server and client will both still use models, views, and controllers:
On the server (ie the Data API). The models are the database/storage access classes. Instead of generating raw HTML the views will be used to format/serialize data for transfer. The controllers work out the messy details between the models and views.
On the client (ie the WebApp client). The models are the functions that handle fetching and deserializing data requests. The views are your html partials that get parsed into static HTML. The controllers /directives manage combining the two.
Can you still do HTML generation on the server-side? Of course. How much work you decide to do in the client vs server depends on your goals.
Then what's the benefit of client-side frameworks? If your goal is to create a SPA, then frameworks like Angular are a much more robust option than the alternitives which would consist of firing off a bunch of AJAX requests, then plugging it into the DOM using something like jQuery.
What's so special about client-side frameworks? Nothing really, they push the responsibility of HTML generation into the client. Instead of splitting HTML templating and dynamic manipulation between the client and server you can now do both in the client. It provides a cleaner separation of concerns and reduces load on the server.
If you need a data layer that can be accesses by multiple platforms (ex IOS, website, Android) then you've likely isolated the data requests into their own API already. If you have that done already, pushing the client-side code to the client makes sense since you're already doing that for the other platforms.
Simplifying the server to just a data layer makes life a simpler for those who develop on multiple platforms. Client-side frameworks made the process of fetching data and generating HTML dynamically on the client much easier. If your goal is to build a SPA, using a framework will provide a good scaffold to build on.
The major downside of client-side HTML generation is that it relies on JavaScript and most search engine webcrawlers are too dumb to use JavaScript. That means, if you have a content-heavy site you're going to have a bad time trying to get search engines to index your content. There are hybrid approaches to conditionally load content generated from the server to webcrawlers but they add another additional layer of complexity so the tradeoffs likely outweigh the benefits.
Best Answer
The server exposes the API and the client makes use of it.
For example, Twitter has data it wants to share (Tweets among other things), so it exposes an API which is served by a REST server (several, in all likelihood). You want to write a mobile app that uses that API to fetch and expose tweets to a user, your mobile app would be the REST client.