edits ch10,11 test row borders

This commit is contained in:
Bill Talcott 2023-03-29 12:55:17 -04:00
parent 373aa57348
commit 6ed901257d
2 changed files with 16 additions and 17 deletions

View File

@ -888,7 +888,7 @@ With this code written, we can make the toolbar appear and disappear, based on w
Very slick.
// useful? or cut css?
Before we move on, you may have noticed our code here includes some "`class=`" references. These are for css styling, and are not part of Alpine.js. We've included them only as a reminder that the menu bar we're building will require some css styling to work well. The classes in the code above refer to a minimal css library called Missing.css. If you use other css libraries, such as Bootstrap, Tailwind, Bulma, Pico.css, etc., your styling classes will be different.
Before we move on, you may have noticed our code here includes some "`class=`" references. These are for css styling, and are not part of Alpine.js. We've included them only as a reminder that the menu bar we're building will require css to work well. The classes in the code above refer to a minimal css library called Missing.css. If you use other css libraries, such as Bootstrap, Tailwind, Bulma, Pico.css, etc., your styling code will be different.
==== Implementing actions

View File

@ -19,8 +19,7 @@ be interpreted, and so on.
Now, believe it or not, we _have_ been creating an API for Contact.app.
This may sound confusing to you: an API? We have just been creating a web application, with handlers that just return
HTML.
This may sound confusing to you: an API? We have just been creating a web application, with handlers that just return HTML.
How is that an API?
@ -41,8 +40,7 @@ common situation in traditional web applications: there is the "`web application
URL, say `https://mywebapp.example.com/`. And there is also a _separate_ JSON API that is accessible through another
URL, perhaps `https://api.mywebapp.example.com/v1`.
This is a perfectly reasonable way to split up the hypermedia interface to your application and the Data API you provide
to other, non-hypermedia clients.
This is a perfectly reasonable way to split up the hypermedia interface to your application and the Data API you provide to other, non-hypermedia clients.
Why would you want to include a Data API along with a hypermedia API? Well, because _non-hypermedia clients_ might also
want to interact with your application as well.
@ -98,26 +96,27 @@ By supporting both of these types of APIs separately you can get the strengths o
styles of code and infrastructure needs cleanly split out.
Let's contrast the needs of JSON APIs with Hypermedia APIs:
// check: row borders?
[cols="a,a"]
[grid=rows]
|===
|JSON API Needs |Hypermedia API
| It must remain stable over time: you cannot change the API willy nilly or you risk breaking clients that use the API
and expect certain end points to behave in certain ways
| There is no need to remain stable over time: all URLs are discovered via HTML responses, so you can be much more aggressive in changing the shape of a hypermedia API
| It must remain stable over time: you cannot change the API willy-nilly or you risk breaking clients that use the API
and expect certain end points to behave in certain ways.
| There is no need to remain stable over time: all URLs are discovered via HTML responses, so you can be much more aggressive in changing the shape of a hypermedia API.
| It must be versioned: related to the first point, when you do make a major change, you need to version the API so that clients that are using the old API continue to work
| This means that versioning is not an issue, another strength of the hypermedia approach
| It must be versioned: related to the first point, when you do make a major change, you need to version the API so that clients that are using the old API continue to work.
| Versioning is not an issue, another strength of the hypermedia approach.
| It should be rate limited: since data APIs are often used by other clients, not just your own internal web application, requests should be rate limited, often by user, in order to avoid a single client overloading the system
| Rate limiting probably isn't as important beyond the prevention of Distributed Denial of Service (DDoS) attacks
| It should be rate limited: since data APIs are often used by other clients, not just your own internal web application, requests should be rate limited, often by user, in order to avoid a single client overloading the system.
| Rate limiting probably isn't as important beyond the prevention of Distributed Denial of Service (DDoS) attacks.
| It should be a general API: since the API is for _all_ clients, not just for your web application, you should avoid specialized end points that are driven by your own application needs. Instead, the API should be general and expressive enough to satisfy as many potential client needs as possible.
| The API can be _very specific_ to your application needs: since it is designed only for your particular web application, and since the API is discovered through hypermedia, you can add and remove highly tuned end points for specific features or optimization needs in your application
| The API can be _very specific_ to your application needs: since it is designed only for your particular web application, and since the API is discovered through hypermedia, you can add and remove highly tuned end points for specific features or optimization needs in your application.
| Authentication for these sorts of API is typically token based, which we will discuss in more detail later
| Authentication is typically managed through a session cookie established by a login page
| Authentication for these sorts of API is typically token based, which we will discuss in more detail later.
| Authentication is typically managed through a session cookie established by a login page.
|===