Update Blog “why-is-redfish®-different-from-other-rest-apis-part-2”

Author: donzef

content/blog/why-is-redfish®-different-from-other-rest-apis-part-2.md

@@ -10,11 +10,11 @@ tags:
 ---
 ## Introduction
 
-The <a href="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1" target="_blank">first part</a> of this article presented the fundamentals of the Redfish® standard published by the "Distributed Management Task Force" (DMTF) consortium. This standard issued in 2015 aims to replace the aging "Intelligent Platform Management Interface" (<a href="https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-home.html" target="_blank">IPMI</a>) to manage the lower layers of the local server or remote servers using a modern REST-type API. The most representative fundamentals are the separation of the protocol from the data modeling, a self-sufficient model and OEM extensions. In this second part, you will find other unique properties contributing to the massive adoption by IT equipment manufacturers of this new method of server management.
+The <a href="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1" target="_blank">first part</a> of this article presented the fundamentals of the Redfish® standard published by the Distributed Management Task Force (DMTF) consortium. This standard issued in 2015 aims to replace the aging Intelligent Platform Management Interface (<a href="https://www.intel.com/content/www/us/en/products/docs/servers/ipmi/ipmi-home.html" target="_blank">IPMI</a>) to manage the lower layers of the local server or remote servers using a modern REST-type API. The most representative fundamentals are the separation of the protocol from the data modeling, a <a href="https://developer.hpe.com/blog/getting-started-with-ilo-restful-api-redfish-api-conformance/" target="_blank">self-describing model</a> and OEM extensions. In this second part, you will find other unique properties contributing to the massive adoption by IT equipment manufacturers of this "hypermedia API".
 
 ## Actions
 
-Redfish® resources support the GET request to retrieve their current state. Modifications or deletions can be performed to certain resources using POST, PUT, PATCH and DELETE requests. Until then, nothing exceptional in the world of REST APIs, except perhaps, that it is possible to retrieve the exhaustive list of possible requests on a given resource, by consulting the `Allow` header of GET request responses.
+Redfish® resources support the GET request to retrieve their current state. Modifications or deletions can be performed to certain resources using POST, PUT, PATCH and DELETE requests. Until then, nothing exceptional in the world of REST APIs, except perhaps, that it is possible to retrieve the exhaustive list of possible requests on a given resource, by consulting the `Allow` header of GET request responses. Refer to the <a href="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1" target="_blank">Allowed requests</a> paragraph in part 1.
 
 However, other types of operations are difficult to model with classic HTTP requests. For example, it is impossible to "read" the server's power button to know its status! Asking for the "return to factory settings" requires something else in the model to be executable.
 
@@ -38,7 +38,7 @@ An alternative to SNMP is the Redfish® Event Service which is based on the subs
 
 ### Event model
 
-Asynchronous events and error messages are all listed and described in registers (see the <a href="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1" target="_blank">first part</a> of this article for an introduction to registers). The registers collection is at the URI `/redfish/v1/Registries`. These objects (events, messages, notifications, etc.) have a common format: `RegistryPrefix.Version.Identifier`. For example, the message for restarting a server (Figure 2) is described in the `Base` registry, version `1.17` and with `Success` as identifier. For more information on this message, simply follow the link `/redfish/v1/Registries/Base` and read the description related to the identifier.
+Asynchronous events and error messages are all listed and described in registers (refer to the <a href="https://developer.hpe.com/blog/why-is-redfish®-different-from-other-rest-apis-part-1" target="_blank">first part</a> of this article for an introduction to registers). The registers collection is at the URI `/redfish/v1/Registries`. These objects (events, messages, notifications, etc.) have a common format: `RegistryPrefix.Version.Identifier`. For example, the message for restarting a server (Figure 2) is described in the `Base` registry, version `1.17` and with `Success` as identifier. For more information on this message, simply follow the link `/redfish/v1/Registries/Base` and read the description related to the identifier.
 
 The exhaustive list of registers that can be used to subscribe to events is returned in the `RegistryPrefixes[]` array of a GET on `/redfish/v1/EventService`. Figure 3 shows an example of such a list from an HPE server. Among other things, there are registers containing messages relating to network and storage equipment.