Replace all http:// links with https://

Because security

Author: spikeheap

docs/api-playbook/Development Lifecycle/API versioning/feauture_toggle.md

@@ -42,7 +42,7 @@ Used to retrieve a list of configurations
   {
     "Type": "Person",
     "Configuration": {
-      "ApiUrl": "http://www.hackney.gov.uk/person"
+      "ApiUrl": "https://www.hackney.gov.uk/person"
     },
     "FeatureToggles": {
       "CreatePerson": true,
@@ -52,7 +52,7 @@ Used to retrieve a list of configurations
   {
     "Type": "ContactDetails",
     "Configuration": {
-      "ApiUrl": "http://www.hackney.gov.uk/contactdetails"
+      "ApiUrl": "https://www.hackney.gov.uk/contactdetails"
     },
     "FeatureToggles": {
       "AddContactDetails": true
@@ -61,7 +61,7 @@ Used to retrieve a list of configurations
   {
     "Type": "Tenure",
     "Configuration": {
-      "ApiUrl": "http://www.hackney.gov.uk/tenure"
+      "ApiUrl": "https://www.hackney.gov.uk/tenure"
     },
     "FeatureToggles": {
       "CreateTenure": true
@@ -70,7 +70,7 @@ Used to retrieve a list of configurations
   {
     "Domain": "Asset",
     "Configuration": {
-      "ApiUrl": "http://www.hackney.gov.uk/asset"
+      "ApiUrl": "https://www.hackney.gov.uk/asset"
     },
     "FeatureToggles": {
       "ViewAsset": false

docs/api-playbook/Development Lifecycle/Designing your API/api_design_principles.md

@@ -10,7 +10,7 @@ We apply the RESTful web service principles to all kind of application (micro-)
 
 We prefer REST-based APIs with JSON payloads.
 
-An important principle for API design and usage is Postel’s Law, aka [The Robustness Principle](http://en.wikipedia.org/wiki/Robustness_principle) (see also [RFC 1122](https://tools.ietf.org/html/rfc1122)):
+An important principle for API design and usage is Postel’s Law, aka [The Robustness Principle](https://en.wikipedia.org/wiki/Robustness_principle) (see also [RFC 1122](https://tools.ietf.org/html/rfc1122)):
 > Be liberal in what you accept, be conservative in what you send.
 
 ### Reading:
@@ -25,7 +25,7 @@ Some interesting reads on the ** RESTful API ** design style and service archite
 
   * [_Web APIs: From Start to Finish_](https://www.infoq.com/minibooks/emag-web-api/) - InfoQ (eMag);
 
-  * [_Thoughts on RESTful API Design_](http://restful-api-design.readthedocs.org/en/latest/) - Lessons-learned blog;
+  * [_Thoughts on RESTful API Design_](https://restful-api-design.readthedocs.org/en/latest/) - Lessons-learned blog;
 
   * [*Architectural Styles and the Design of Network-Based Software Architectures*](https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm) - Roy Fielding (Dissertation);
 

docs/api-playbook/Development Lifecycle/Designing your API/compatibility.md

@@ -36,7 +36,7 @@ Service clients should apply the robustness principle:
 
 Service clients must be prepared for compatible API extensions of service providers:
 
-  - Be tolerant with unknown fields in the payload (see also Fowler’s ["TolerantReader"](http://martinfowler.com/bliki/TolerantReader.html) post), i.e. ignore new fields but do not eliminate them from payload if needed for subsequent PUT requests;
+  - Be tolerant with unknown fields in the payload (see also Fowler’s ["TolerantReader"](https://martinfowler.com/bliki/TolerantReader.html) post), i.e. ignore new fields but do not eliminate them from payload if needed for subsequent PUT requests;
 
   - Be prepared to handle HTTP status codes not explicitly specified in endpoint definitions. Note also, that status codes are extensible. Default handling is how you would treat the corresponding x00 code (see [RFC7231 Section 6](https://tools.ietf.org/html/rfc7231#section-6));
 
@@ -63,7 +63,7 @@ Not ignoring unknown input fields is a specific deviation from Postel’s Law (e
 In specific situations, where a (known) input field is not needed anymore, it either can stay in the API definition with "not used anymore" description or can be removed from the API definition as long as the server ignores this specific parameter.
 ## SHOULD Avoid Versioning:
 
-When changing your RESTful APIs, do so in a compatible way and avoid generating additional API versions. Multiple versions can significantly complicate understanding, testing, maintaining, evolving, operating and releasing our systems [supplementary reading](http://martinfowler.com/articles/enterpriseREST.html)).
+When changing your RESTful APIs, do so in a compatible way and avoid generating additional API versions. Multiple versions can significantly complicate understanding, testing, maintaining, evolving, operating and releasing our systems [supplementary reading](https://martinfowler.com/articles/enterpriseREST.html)).
 
 If changing an API can’t be done in a compatible way, then proceed in one of these three ways:
 

docs/api-playbook/Development Lifecycle/Designing your API/data-formats.md

@@ -78,7 +78,7 @@ Other media types may be used in following cases:
 Represent date and time format as [RFC 3339](#should-date-property-values-should-conform-to-rfc-3339).
 ### HTTP headers:
 
-HTTP headers including the proprietary headers use the [HTTP date format defined in RFC 7231](http://tools.ietf.org/html/rfc7231#section-7.1.1.1).
+HTTP headers including the proprietary headers use the [HTTP date format defined in RFC 7231](https://tools.ietf.org/html/rfc7231#section-7.1.1.1).
 
 ## MAY Use Standards for Country, Language and Currency Codes:
 
@@ -136,14 +136,14 @@ components:
 
 ## SHOULD Date property values should conform to RFC 3339:
 
-Use the date and time formats defined by [RFC 3339](http://tools.ietf.org/html/rfc3339#section-5.6):
+Use the date and time formats defined by [RFC 3339](https://tools.ietf.org/html/rfc3339#section-5.6):
 
   - for "date" use strings matching `date-fullyear "-" date-month "-" date-mday`, for example: `2015-05-28`;
 
   - for "date-time" use strings matching `full-date "T" full-time`, for example `2015-05-28T14:07:17Z`;
 
 Note that the [OpenAPI format](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types)
-"date-time" corresponds to "date-time" in the RFC) and `2015-05-28` for a date (note that the OpenAPI format "date" corresponds to "full-date" in the RFC). Both are specific profiles, a subset of the international standard [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601).
+"date-time" corresponds to "date-time" in the RFC) and `2015-05-28` for a date (note that the OpenAPI format "date" corresponds to "full-date" in the RFC). Both are specific profiles, a subset of the international standard [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601).
 
 A zone offset may be used (both, in request and responses) — this is simply defined by the standards. However, we encourage restricting dates to UTC and without offsets. For example `2015-05-28T14:07:17Z` rather than `2015-05-28T14:07:17+00:00`. From experience we have learned that zone offsets are not easy to understand and often not correctly handled. Note also that zone offsets are different from local times that might be including daylight saving time. Localization of dates should be done by the services that provide user interfaces, if required.
 
@@ -159,10 +159,10 @@ Schema based JSON properties that are by design durations and intervals could be
 
 ## SHOULD Use standards for Language, Country and Currency:
 
-  - [ISO 3166-1-alpha2 country](http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2);
+  - [ISO 3166-1-alpha2 country](https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2);
 
   - [ISO 639-1 language code](https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes);
 
   - [BCP-47](https://tools.ietf.org/html/bcp47) (based on ISO 639-1) for language variants;
 
-  - [ISO 4217 currency codes](http://en.wikipedia.org/wiki/ISO_4217);
+  - [ISO 4217 currency codes](https://en.wikipedia.org/wiki/ISO_4217);

docs/api-playbook/Development Lifecycle/Designing your API/http.md

@@ -2,7 +2,7 @@
 
 ## MUST Use REST Maturity Level 2:
 
-We strive for a good implementation of [REST Maturity Level 2](http://martinfowler.com/articles/richardsonMaturityModelhtml#level2) as it enables us to build resource-oriented APIs that make full use of HTTP verbs and status codes. You can see this expressed by many rules throughout these guidelines, e.g.:
+We strive for a good implementation of [REST Maturity Level 2](https://martinfowler.com/articles/richardsonMaturityModelhtml#level2) as it enables us to build resource-oriented APIs that make full use of HTTP verbs and status codes. You can see this expressed by many rules throughout these guidelines, e.g.:
 
   - [Avoid Actions — Think About Resources](resources.md#must-avoid-actions--think-about-resources);
 
@@ -73,11 +73,11 @@ PATCH requests are used to **update parts** of single resources, i.e. where only
 
 2.  Use PATCH with partial objects to only update parts of a resource, whenever possible. (This is basically [JSON Merge Patch](https://tools.ietf.org/html/rfc7396),a specialized media type `application/merge-patch+json` that is a partial resource representation.);
 
-3.  Use PATCH with [JSON Patch](http://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
+3.  Use PATCH with [JSON Patch](https://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
 
 4.  Use POST (with a proper description of what is happening) instead of PATCH, if the request does not modify the resource in a way defined by the semantics of the media type;
 
-In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](http://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](http://erosb.github.io/post/json-patch-vs-merge-patch)).
+In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](https://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](https://erosb.github.io/post/json-patch-vs-merge-patch)).
 
 ### DELETE:
 
@@ -111,7 +111,7 @@ Content or entity headers are headers with a `Content-` prefix. They describe th
 
 ## MAY Use Other Standardized Headers:
 
-Use [this list](http://en.wikipedia.org/wiki/List_of_HTTP_header_fields) and mention its support in your OpenAPI definition.
+Use [this list](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields) and mention its support in your OpenAPI definition.
 
 ## MUST Fulfill Safeness and Idempotency Properties:
 
@@ -247,7 +247,7 @@ The before rules apply *even in the case* that processing of all individual part
 
 ## MUST Use Code 429 with Headers for Rate Limits:
 
-APIs that wish to manage the request rate of clients must use the ['429 Too Many Requests'](http://tools.ietf.org/html/rfc6585) response code if the client exceeded the request rate and therefore the request can’t be fulfilled. Such responses must also contain header information providing further details to the client. There are two approaches a service can take for header information:
+APIs that wish to manage the request rate of clients must use the ['429 Too Many Requests'](https://tools.ietf.org/html/rfc6585) response code if the client exceeded the request rate and therefore the request can’t be fulfilled. Such responses must also contain header information providing further details to the client. There are two approaches a service can take for header information:
 
   - Return a ['Retry-After'](https://tools.ietf.org/html/rfc7231#section-7.1.3) header indicating how long the client ought to wait before making a follow-up request. The Retry-After header can contain a HTTP date value to retry after or the number of seconds to delay. Either is acceptable but APIs should prefer to use a delay in seconds;
 

docs/api-playbook/Development Lifecycle/Designing your API/pagination.md

@@ -47,6 +47,6 @@ Further reading:
 
   - [Twitter](https://dev.twitter.com/rest/public/timelines);
 
-  - [Use the Index, Luke](http://use-the-index-luke.com/no-offset);
+  - [Use the Index, Luke](https://use-the-index-luke.com/no-offset);
 
   - [Paging in PostgreSQL](https://www.citusdata.com/blog/1872-joe-nelson/409-five-ways-paginate-postgres-basic-exotic);

docs/api-playbook/Development Lifecycle/Designing your API/references.md

@@ -38,7 +38,7 @@ This section collects links to documents to which we refer, and base our guideli
 
   - [Build APIs You Won’t Hate](https://leanpub.com/build-apis-you-wont-hate);
 
-  - [InfoQ eBook - Web APIs: From Start to Finish](http://www.infoq.com/minibooks/emag-web-api);
+  - [InfoQ eBook - Web APIs: From Start to Finish](https://www.infoq.com/minibooks/emag-web-api);
 ## Blogs:
 
-  - [Lessons-learned blog: Thoughts on RESTful API Design](http://restful-api-design.readthedocs.org/en/latest/);
+  - [Lessons-learned blog: Thoughts on RESTful API Design](https://restful-api-design.readthedocs.org/en/latest/);

docs/api-playbook/Development Lifecycle/How to build an API/Preferred tech stack/serverless_lambda.md

@@ -28,7 +28,7 @@ functions:
     environment:
       CONNECTION_STRING: Host=${ssm:/example-api/${self:provider.stage}/postgres-hostname};Port=${ssm:/example-api/${self:provider.stage}/postgres-port};Database=example-api-mirror;Username=${ssm:/example-api/${self:provider.stage}/postgres-username};Password=${ssm:/example-api/${self:provider.stage}/postgres-password}
     events:
-      - http:
+      - https:
           path: /{proxy+}
           method: ANY
           private: true

docs/api-playbook/Development Lifecycle/Implementing HTTP endpoints/PATCH endpoint/patch_dynamodb.md

@@ -19,11 +19,11 @@ PATCH requests are used to **update parts** of single resources, i.e. where only
 
 2.  Use PATCH with partial objects to only update parts of a resource, whenever possible. (This is basically [JSON Merge Patch](https://tools.ietf.org/html/rfc7396),a specialized media type `application/merge-patch+json` that is a partial resource representation.);
 
-3.  Use PATCH with [JSON Patch](http://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
+3.  Use PATCH with [JSON Patch](https://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
 
 4.  Use POST (with a proper description of what is happening) instead of PATCH, if the request does not modify the resource in a way defined by the semantics of the media type;
 
-In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](http://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](http://erosb.github.io/post/json-patch-vs-merge-patch)).
+In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](https://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](https://erosb.github.io/post/json-patch-vs-merge-patch)).
 
 [Here is an example PR to show how to build a PATCH endpoint using DynamoDB](https://github.com/LBHackney-IT/tenure-api/pull/45/files)
 

docs/api-playbook/Development Lifecycle/Implementing HTTP endpoints/PATCH endpoint/patch_postgres.md

@@ -19,11 +19,11 @@ PATCH requests are used to **update parts** of single resources, i.e. where only
 
 2.  Use PATCH with partial objects to only update parts of a resource, whenever possible. (This is basically [JSON Merge Patch](https://tools.ietf.org/html/rfc7396),a specialized media type `application/merge-patch+json` that is a partial resource representation.);
 
-3.  Use PATCH with [JSON Patch](http://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
+3.  Use PATCH with [JSON Patch](https://tools.ietf.org/html/rfc6902), a specialized media type `application/json-patch+json` that includes instructions on how to change the resource;
 
 4.  Use POST (with a proper description of what is happening) instead of PATCH, if the request does not modify the resource in a way defined by the semantics of the media type;
 
-In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](http://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](http://erosb.github.io/post/json-patch-vs-merge-patch)).
+In practice [JSON Merge Patch](https://tools.ietf.org/html/rfc7396) quickly turns out to be too limited, especially when trying to update single objects in large collections (as part of the resource). In this cases [JSON Patch](https://tools.ietf.org/html/rfc6902) can shown its full power while still showing readable patch requests (see also [JSON patch vs. merge](https://erosb.github.io/post/json-patch-vs-merge-patch)).
 
 We have created a video that gives developers a good understanding of how we build API Endpoints using Postgres from beginning to end, following best practices.