fix typos

content/post/soaping-with-rest.md

@@ -11,11 +11,11 @@ My first impulse was to panic. Who writes SOAP services anymore? Who has any ide
 Turns out, it's actually not that hard. While SOAP is more rigid and intensive in terms of its xml messaging protocol specifications, and what is to be done with its payloads at the nodes, it is actually utterly platform and application layer independent. Which means you could, theoretically use SOAP as a messaging protocol over SMTP, FTP, DNS, or HTTP. The same is not the case for REST, which is designed to use the features of the HTTP protocol to facilitate uniform lightweight communications between network attached devices. So, there's nothing stopping me from using SOAP as a payload on an HTTP request. In fact, when you look at network traffic between two applications talking to each other in SOAP, looks an awful lot like two applications talking to each other in REST, but with two important differences: 
 
 1. All of the request calls are POST calls (there are no GET, PUT, or DELETE calls, because the functions represented by those, are built into the xml document object itself).
-2. All of the payload Media-Types are either `application/xml` or `text/xml` (depending on the version of SOAP in use, though I was unable to see any difference using either, in experimentation).
+2. All of the payload `Content-Type`'s are either `application/xml` or `text/xml` (depending on the version of SOAP in use, though I was unable to see any difference using either, in experimentation).
 
 This being the case, I decided to try something sneaky. I happen to be somewhat handy at Java Springboot (who isn't these days). Could I just stand up a Springboot application, and have it serve xml responses that would be appropriate to what the original service would have produced, had it received the request and fully processed it? I wouldn't be doing any processing. All I'd have to do, is convert the incoming request body into an xml document, look for what's being requested, and then respond with an appropriate xml body that looked as if it were an actual processed response. 
 
-That's exactly what I did. And it worked like a champ. To set this up in Springboot turns out to be really simple, as well. It's not strictly necessary to do this, but the first thing I did was to set up the framework to always default to a `Media-Type` of `text/xml`:
+That's exactly what I did. And it worked like a champ. To set this up in Springboot turns out to be really simple, as well. It's not strictly necessary to do this, but the first thing I did was to set up the framework to always default to a `Content-Type` of `text/xml`:
 
 ```java
 @Configuration
@@ -41,7 +41,7 @@ Since Springboot is Java, you could skip the configuration, and just put the Med
 public class MockController {
 ```
 
-No path is specified here, because we're going to do that at the method level. But every method will now default to both `Accept: text/xml` and `Media-Type: text/xml`, when they interact over HTTP. Note also, that I'm using `@RestController`, and not `@Controller`. This was counter-intuitive for me, at first. But paradoxically, it is indeed the `@RestController` you want. This is for a few reasons. First, from the standpoint of the HTTP layer, there's literally no difference between an xml response body produced by the RestController, and one produced by the Controller. Since the former is easier to work with, just go with it. Second, it is in fact, easier to work with, when all you're doing is mocking. If I were to employ the Controller instead, I'd have to build a service layer unmarshalling the xml and constructing a response body from objects. Otherwise, you'll get `Unsupported Protocol` errors. 
+No path is specified here, because we're going to do that at the method level. But every method will now default to both `Accept: text/xml` and `Content-Type: text/xml`, when they interact over HTTP. Note also, that I'm using `@RestController`, and not `@Controller`. This was counter-intuitive for me, at first. But paradoxically, it is indeed the `@RestController` you want. This is for a few reasons. First, from the standpoint of the HTTP layer, there's literally no difference between an xml response body produced by the RestController, and one produced by the Controller. Since the former is easier to work with, just go with it. Second, it is in fact, easier to work with, when all you're doing is mocking. If I were to employ the Controller instead, I'd have to build a service layer unmarshalling the xml and constructing a response body from objects. Otherwise, you'll get `Unsupported Protocol` (415) errors. 
 
 Finally, we get to the actual controller method. This is just a generic example of what I actually ended up building for my job. So, some of the decision logic is not presented here. But, there's enough present to make it clear. Technically, you could just search the body string for whatever you wanted, but I thought I'd be a bit more sophisticated than that. I convert the response body into an actual xml document, and then look for the nodes I'm expecting, to tell me what canned-response to ship back. This is what it looks like: