removed space in image links

Author: AllanHoejgaardJensen

md/findings-report.md

@@ -13,7 +13,7 @@ considering this response they would not react appropriate to the response. If t
 `200` or a `404`, they would not have considered `202` and following the `location` header after waiting the amount of time 
 suggested by the `retry-after` header.  That is why this is considered a breaking change.
 
- ![202 as breaking change to the API] (../sample-reports/202_added_breaking.png)
+ ![202 as breaking change to the API](../sample-reports/202_added_breaking.png)
 
 The `202` may be a response that services needs to introduce, if e.g. the time it takes to complete the response increases 
 over time due to whatever reasons, it could be a creation of information that due to changes in legislation takes longer. 
@@ -27,50 +27,50 @@ back, the client would not be ready to react by following the `location` header
 Adding a `301` and `307` to your API makes it easier to move endpoints and having that as a part of your Open API 
 specification may be worth considering.
 
- ![301 as breaking change to the API] (../sample-reports/301_added_good_pot-breaking.png)
+ ![301 as breaking change to the API](../sample-reports/301_added_good_pot-breaking.png)
 
- ![307 as breaking change to the API] (../sample-reports/307_added_pot-breaking.png)
+ ![307 as breaking change to the API](../sample-reports/307_added_pot-breaking.png)
 
 Having an existing API ` (!) ` where a `301` or `307` is not defined is therefore reported as something you evaluate if yu want 
 to include in your API or not.
 
- ![301 missing in the existing API is a breaking change waiting to happen] (../sample-reports/301_missing_pot-break.png)
+ ![301 missing in the existing API is a breaking change waiting to happen](../sample-reports/301_missing_pot-break.png)
 
 Having the ability to offer a "service" to clients where they can ask if the need to re-read a resource or whether the 
 client still has a valid version of the resource is the reason for including `304` in the potentially breaking part. 
 Therefore an existing API without `304` might want to be extended with that, the reason for it being perceived as 
 breaking is a scalability perspective as this can allow som services (having resources with a non-realtime character)
 to scale higher (or have a lower operational cost for the same load).
 
- ![304 missing in the existing API is a potential for offloading services] (../sample-reports/304_missing_pot-break.png)
+ ![304 missing in the existing API is a potential for offloading services](../sample-reports/304_missing_pot-break.png)
 
 The most frequent used responses are probably `200` and `404`, failing to have these as a part of the existing API or the 
 new is considered a potential breaking change.
 
- ![404 missing in the API is a potential break] (../sample-reports/404_missing_pot-break.png)
+ ![404 missing in the API is a potential break](../sample-reports/404_missing_pot-break.png)
 
 If the `200` is added to the new API it needs to include som headers like `X-Log-Token` to enable clients to refer to 
 incidents in a way of their choosing and in that way handle bugs etc. more efficient, here the some headers concerning
 rate limits are added as required by the service in the new version of the API, which makes a lot of sense, as they are 
 required this is considered a breaking change to the new API.
 
- ![200 missing in the API is a potential break] (../sample-reports/200_limit-breaking.png)
+ ![200 missing in the API is a potential break](../sample-reports/200_limit-breaking.png)
 
 If a client sets the `Accept` header to a content-type unknown to the server, some services are responding with a `400`, 
 whereas the `415` seems more appropriate for this situation, in order to avoid breaking the API when introducing this 
 response code later it seems like a good and sound idea to include this from the start.
 
- ![415 missing in the existing API is a potential break waiting to happen] (../sample-reports/415_missing_pot-break.png)
+ ![415 missing in the existing API is a potential break waiting to happen](../sample-reports/415_missing_pot-break.png)
 
 Including a number of responses from the start seems to worth considering, which is why a number of these are considered 
 potential breaks, se below.
 
- ![429 missing in the existing API is a potential break waiting to happen] (../sample-reports/429_missing_pot-break.png)
+ ![429 missing in the existing API is a potential break waiting to happen](../sample-reports/429_missing_pot-break.png)
 
 Not having this as a part of your API means you cannot ask client politely to back off for 
 a while (specified in the `retry-after`) header
 
- ![412 missing in the existing API is a more precise way to signal pre-conditional errors to clients] (../sample-reports/412_missing_pot-break.png)
+ ![412 missing in the existing API is a more precise way to signal pre-conditional errors to clients](../sample-reports/412_missing_pot-break.png)
 
 This is a more specific error in the event of validation errors, in many situations the `400` is used and it may, the 
 `412` is a little more precise for pre-conditional validation issues. `400` is considered as one of the mandatory alongside 
@@ -81,7 +81,7 @@ How long must you remember an endpoint, if you did not have the `301` or `307` s
 endpoints and you know that you want to be able to terminate a given endpoint someday somehow. This is where `410` comes 
 into the picture:
 
- ![410 missing in the existing API is a potential break waiting to happen] (../sample-reports/410_missing_pot-break.png)
+ ![410 missing in the existing API is a potential break waiting to happen](../sample-reports/410_missing_pot-break.png)
 
 This is arguable whether this should be a mandatory response in every endpoint in a service or not, it is however worth 
 considering whether it is something you need. If not specified, the contracts and terms for bringing an endpoint down 
@@ -91,20 +91,20 @@ The `505` response is making ready for the next version of HTTP, so it is kind o
 endpoints down or can you cease the support for a given version of content, of API structure and how to do that using 
 HTTP response code and other mechanisms to do it in a way that the clients can understand and follow.
 
- ![505 missing in the existing API is a potential break waiting to happen] (../sample-reports/505_missing_pot-break.png)
+ ![505 missing in the existing API is a potential break waiting to happen](../sample-reports/505_missing_pot-break.png)
 
 The error handling from the services side are usually done by 500 and possibly 503 and thus they must be part of the 
 responses that any endpoint can return.
 
- ![500 missing in the existing API is a potential break waiting to happen] (../sample-reports/500_missing_pot-break.png)
+ ![500 missing in the existing API is a potential break waiting to happen](../sample-reports/500_missing_pot-break.png)
 
- ![503 missing in the existing API is a potential break waiting to happen] (../sample-reports/503_missing_pot-break.png)
+ ![503 missing in the existing API is a potential break waiting to happen](../sample-reports/503_missing_pot-break.png)
 
  The `503` is suggested having a `retry-after` header to signal back to the client when the service is expected to be 
  available again, the aim of that is that clients can use this for information to the application user and thus informing 
  the users to prepare the user for this situation the best the client can. 
 
-  ![503 retry-after header is required] (../sample-reports/503_added_required_header-breaking.png)
+  ![503 retry-after header is required](../sample-reports/503_added_required_header-breaking.png)
 
 Adding that header and make it required is a potentially breaking thing as clients may not do anything about the header 
 and thus the service downtime (or slow performance) may continue. Again here you could argue that this type of header
@@ -116,52 +116,52 @@ e.g. with a certified level according to a given Open API Diff profile.
 The response code regarding authorization and access `401` and `403` must be part of any protected API and thus they 
 are included in the mandatory set of responses here.
 
-  ![401 missing in the existing API is a potential break waiting to happen] (../sample-reports/401_missing_pot-break.png)
+  ![401 missing in the existing API is a potential break waiting to happen](../sample-reports/401_missing_pot-break.png)
 
 
 The elaborated part of the reports attempt to state a few words on the observation:
 
-  ![The elaborated report on responses] (../sample-reports/addedResponsesChange.png)
+  ![The elaborated report on responses](../sample-reports/addedResponsesChange.png)
 
 and 
 
-  ![The elaborated report on responses] (../sample-reports/Compliance_Responses_Change.png)
+  ![The elaborated report on responses](../sample-reports/Compliance_Responses_Change.png)
 
 
 On top of that there are som even more opinionated parts, such as the parts on using content-types as versioning 
 mechanism for content in endpoints:
 
-  ![The elaborated report on content types] (../sample-reports/Compliance_ContentTypes.png)
+  ![The elaborated report on content types](../sample-reports/Compliance_ContentTypes.png)
 
-  ![The elaborated report on content types projection added] (../sample-reports/projectionAdded.png)
+  ![The elaborated report on content types projection added](../sample-reports/projectionAdded.png)
 
 
 And concrete observations like: 
 
-  ![The elaborated report on content types] (../sample-reports/descriptionExtended-pot-break.png)
+  ![The elaborated report on content types](../sample-reports/descriptionExtended-pot-break.png)
 
-  ![The elaborated report on content types] (../sample-reports/header_pattern_changed-pot-break.png)
+  ![The elaborated report on content types](../sample-reports/header_pattern_changed-pot-break.png)
 
-  ![The elaborated report on content types] (../sample-reports/ResponseCode_200_changes.png)
+  ![The elaborated report on content types](../sample-reports/ResponseCode_200_changes.png)
 
-  ![The elaborated report on content types] (../sample-reports/property_changed_to_required.png)
+  ![The elaborated report on content types](../sample-reports/property_changed_to_required.png)
 
 And:
 
-  ![The elaborated report on header changes] (../sample-reports/descriptionExtended-pot-break.png)
+  ![The elaborated report on header changes](../sample-reports/descriptionExtended-pot-break.png)
 
-  ![The elaborated report on path parameter changes] (../sample-reports/projectionAdded.png)
+  ![The elaborated report on path parameter changes](../sample-reports/projectionAdded.png)
 
 And suggested improvements to the existing design - here in the form of suggesting that null is not a good definition 
 to have in the API, because it creates uncertainty going forward with your design and the greater the number of client 
 the services have the larger the risk for various interpretations of a given set of input or output and thus the service 
 developers themselves are less clear on what the clients may experience as a result of a change.
 
-  ![The elaborated report on content types] (../sample-reports/designImprovement.png)
+  ![The elaborated report on content types](../sample-reports/designImprovement.png)
 
 And:
 
-  ![The elaborated report on content types] (../sample-reports/pattern_from_null_pot-break.png)
+  ![The elaborated report on content types](../sample-reports/pattern_from_null_pot-break.png)
 
 ## Opinionated parts
 The opinionated parts are:

md/html-report.md

@@ -5,20 +5,20 @@ A with a bit of explanation to each of the screenshots will follow:
 
 ## Introduction
 
-![HTML Intro] (../sample-reports/HTML-Intro.png)
+![HTML Intro](../sample-reports/HTML-Intro.png)
 
 The introductory part of the report is to state what is going to be in the report and how the notation of the report
 should be understood.
 
 ## The Quick Overview
 
-![HTML Overview] (../sample-reports/HTML-Overview.png)
+![HTML Overview](../sample-reports/HTML-Overview.png)
 
 The overview section gives a highlevel overview over what has happened as "The Big Picture" perspective
 
 ## Elaboration on Changed Parts
 
-![HTML Elaborated Change] (../sample-reports/HTML-Elaborated-Change.png)
+![HTML Elaborated Change](../sample-reports/HTML-Elaborated-Change.png)
 
 The elaborated section gives a more detailed overview over what has happened and what is the issues found that leads to 
 breaking situations that will disturb the clients (user of the service) and the potentially breaking situations, that 
@@ -28,7 +28,7 @@ and deployment speed for the service developers.
 
 ## Elaboration on Opinionated Compliance
 
-![HTML Elaborated Compliance] (../sample-reports/HTML-Elaborated-Compliance.png)
+![HTML Elaborated Compliance](../sample-reports/HTML-Elaborated-Compliance.png)
 
 The elaborated section including every observation found to be of interest in relation to compliance to the opinionated 
 view on APIs that should be easy to evolve. 

md/markdown-report.md

@@ -6,14 +6,14 @@ A with a bit of explanation to each of the screenshots will follow:
 
 ## The Introduction and Quick Overview
 
-![Markdown Intro and Overview] (../sample-reports-reports/MD-Intro.png)
+![Markdown Intro and Overview](../sample-reports/MD-Intro.png)
 
 The introductory part of the report is to state what is going to be in the report and how the notation of the report
 should be understood. The Overview section gives a highlevel overview over what has happened as "The Big Picture" perspective.
 
 ## Elaboration on Changed Parts
 
-![Markdown Elaborated Change] (../sample-reports/MD-Elaborated-Change.png)
+![Markdown Elaborated Change](../sample-reports/MD-Elaborated-Change.png)
 
 The elaborated section gives a more detailed overview over what has happened and what is the issues found that leads to 
 breaking situations that will disturb the clients (user of the service) and the potentially breaking situations, that 
@@ -23,7 +23,7 @@ and deployment speed for the service developers.
 
 ## Elaboration on Opinionated Compliance
 
-![Markdown Elaborated Compliance] (../sample-reports/MD-Elaborated-Compliance.png)
+![Markdown Elaborated Compliance](../sample-reports/MD-Elaborated-Compliance.png)
 
 The elaborated section including every observation found to be of interest in relation to compliance to the opinionated 
 view on APIs that should be easy to evolve. 

md/text-report.md

@@ -7,14 +7,14 @@ A with a bit of explanation to each of the screenshots will follow:
 
 ## The Introduction and Quick Overview
 
-![Console Intro and Overview] (../sample-reports/CONSOLE-IntroAndOverview.png)
+![Console Intro and Overview](../sample-reports/CONSOLE-IntroAndOverview.png)
 
 The introductory part of the report is to state what is going to be in the report and how the notation of the report
 should be understood. The Overview section gives a highlevel overview over what has happened as "The Big Picture" perspective.
 
 ## Elaboration on Changed Parts
 
-![Console Elaborated Change] (../sample-reports/CONSOLE-Elaborated-Change.png)
+![Console Elaborated Change](../sample-reports/CONSOLE-Elaborated-Change.png)
 
 The elaborated section gives a more detailed overview over what has happened and what is the issues found that leads to 
 breaking situations that will disturb the clients (user of the service) and the potentially breaking situations, that 
@@ -24,13 +24,13 @@ and deployment speed for the service developers.
 
 ## Elaboration on Opinionated Compliance
 
-![Console Elaborated Compliance] (../sample-reports/CONSOLE-Elaborated-Compliance.png)
+![Console Elaborated Compliance](../sample-reports/CONSOLE-Elaborated-Compliance.png)
 
 The elaborated section including every observation found to be of interest in relation to compliance to the opinionated 
 view on APIs that should be easy to evolve. 
 The observations are breaking, potentially breaking, changes and suggested improvements to the service design as well as 
 details for the headers, parameters, properties, content-types, responses.
 
-![Text Intro and Overview] (../sample-reports/TXT-IntroAndOverview.png)
+![Text Intro and Overview](../sample-reports/TXT-IntroAndOverview.png)
 
 Will display the same as the console part, with the console coloring filtered.