{"id":2240,"date":"2014-08-11T21:57:26","date_gmt":"2014-08-11T09:57:26","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2240"},"modified":"2014-08-12T14:13:11","modified_gmt":"2014-08-12T02:13:11","slug":"delayed-post-response","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2240\/","title":{"rendered":"Delayed POST Response"},"content":{"rendered":"[Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span>

Way back in September last year, Mason Wheeler blogged about his first experiences with developing for Android using Oxygene.<\/a> I said at the time that I would look into reproducing his efforts and respond.<\/p>\n

<\/p>\n

I didn’t get around to that right away and, as I think I have mentioned previously, then got rather busy and honestly, I completely forgot about it. My bad. \ud83d\ude41<\/p>\n

But Mason mentioned this post again the RemObjects Talk forums recently and appears to be under the impression that he has found some fundamentally broken aspect of Android. I think he is mistaken and ironically simply needs to take his own advice.<\/p>\n

The entirety of his post can be summed up in one sentence that is actually found within the post itself:<\/p>\n

If you don\u2019t know anything about it, it might take a bit of time to research it. But once you do know about it, this only takes a few minutes to write, and it works.<\/p><\/blockquote>\n

When made in the original post this statement refers to the obscurity of the Indy-based mechanism class dealing with multipart forms. The irony being that almost every criticism he then goes on to level at the “Android” approach to his simple problem can be dismissed with exactly the same response.<\/p>\n

Threading<\/h2>\n

First of all there is the complaint that you are not permitted to perform network calls in the UI thread on Android. <\/p>\n

But surely anybody that has done any serious network coding – even in Delphi – knows that this is just good sense. And the same applies with Indy. “Why is my UI locking up when I make a HTTP request ?<\/em>” is a common refrain among Indy “newbies” (and not so newbies). So I see this being enforced as no bad thing. Start as you mean to go on and all that.<\/p>\n

Really, it’s not that difficult, and better to learn the right approach at the start, rather than getting into all sorts of bad habits that you are then forced to deal with only later when you have to unlearn those habits and potentially re-write a whole heap of code that you didn’t realise was going to cause you grief (so gosh-darned easy was it to write).<\/p>\n

But I digress.<\/p>\n

It is stated that AsyncTask<\/strong> is “how you run something in a background thread on an Android device<\/em>“.<\/p>\n

Which is not quite accurate.<\/p>\n

AsyncTask<\/strong> is only one<\/em> way to achieve this, and not always the most appropriate or straightforward. In fact, I haven’t yet felt the need to use AsyncTask<\/strong> so can’t speak to whether it is truly a “mess” or if perhaps instead simply not enough time was spent researching it for the purposes of his blog post case.<\/p>\n

What I can say is that one alternative that I have used, and used on this occasion – using a subclassed Thread<\/strong> – is simplicity itself and that the Android equivalent of “Synchronize()” for then performing UI updates on the UI thread is similarly straightforward, involving a simple, inline, anonymous subclass of a Runnable<\/strong> with an overridden run()<\/strong> method containing your UI code, which you then pass to the appropriate Activity.runOnUiThread()<\/strong>.<\/p>\n

Having said that, if you don\u2019t know anything about it, it might take a bit of time to research it. But once you do know about it, this only takes a few minutes to write, and it works<\/em><\/strong>.<\/p>\n

Here is the thread subclass:<\/p>\n

\r\n  POSTThread = public class(Thread)\r\n  public\r\n    method run; override;\r\n  end;\r\n<\/pre>\n
And here is the code in a button click listener for starting this thread:<\/p>\n
\r\n    new POSTThread().start;\r\n<\/pre>\n
I didn’t even really need an explicit class.  I could have used an anonymous, inline class for this as well, but it helped on this occasion I think to make the Thread<\/strong> more obviously explicit, for illustrative purposes.  But I’ll demonstrate anonymous inline classes when I come to show the implementation of the run()<\/strong> method at the end of this post (which will also then show how to easily perform code on the UI thread).<\/p>\n
Meanwhile, moving on to Mason’s next problem…<\/p>\n
URLEncoded or MultipartForm ?<\/h2>\n
Make up your Mind<\/h3>\n
Irritation is then expressed at the hassle involved in setting up a multipart form request.<\/p>\n
The mistake that I think was made here was that the research tool used was code completion suggestions and guesswork.  Things were identified that looked like they corresponded to the way that Indy worked, and assumptions then made about how they work.<\/p>\n
It certainly seems that there was no attempt to initially research how multi-part form content is best formed on Android.  For, had this been done, the Apache MultipartEntityBuilder<\/strong> class would quickly have been discovered.<\/p>\n
Certainly this is not part of the Android framework.  But it is an open source library that is easily added to an Oxygene project.  Simply download and unzip the jars and add two references to the solution (httpcore-4.3.2 and httpmime-4.3.5).  Yes, these are Java libraries, but Oxygene speaks Java like a native, so this is not a problem.  At all.<\/p>\n
Curiously, when Mason posted his problem on StackOverflow<\/a>, he then accepted an answer which did not actually meet his needs !<\/p>\n
The answer he accepted yields a x-www-form-urlencoded<\/strong> entity in his request, not a multi-part form.  It is also unnecessarily complex<\/em>.<\/p>\n
Here’s the code for actually setting up a multi-part form request, as specified in his original Delphi\/Indy code:<\/p>\n
\r\n  var\r\n    req: HttpPost;\r\n    mpe: MultipartEntityBuilder;\r\n  begin\r\n    req   := new HttpPost('http:\/\/posttestserver.com\/post.php');\r\n\r\n    mpe := MultipartEntityBuilder.create;\r\n    mpe.addTextBody('Username', 'test');\r\n    mpe.addTextBody('Password', 'password');\r\n    mpe.addTextBody('cmd',      'Login');\r\n\r\n    req.Entity := mpe.build;\r\n  end;\r\n<\/pre>\n
Once you get there, this is hardly a million miles away from the Indy approach, is it ?  Different, yes.  Of course.  But we’re not talking Chalk vs Cheese<\/strong>.  More like Brie vs Camembert<\/strong>.  \ud83d\ude42<\/p>\n
Yes, it’s different when compared to Indy and if you don\u2019t know anything about it, it might take a bit of time to research it. But once you do know about it, this only takes a few minutes to write, and it works<\/em><\/strong>.<\/p>\n
You can see from this code that my test is going to make use of a generously provided public web server specifically for testing POST requests<\/a>.  It’s not exactly complicated.  Now, this server won’t enable me to test another of Mason’s complaints (the response to a 302 redirect) but we’ll deal with that when we get to it.<\/p>\n
Meanwhile, worth noting is that this in fact is the bulk of the code in my entire working example.<\/p>\n
It’s the Same !!<\/h2>\n
Mason got into such a habit of complaining about Android that he manages to accuse it of behaving in exactly the same way as Indy and turn this into a criticism.<\/p>\n
It is observed that the HttpPost<\/strong> class (or instance thereof) doesn’t do anything and that you have to use an HttpClient<\/strong>.  Last time I checked, the Indy TIdHttpRequest<\/strong> doesn’t do anything either.  You have to use a TIdHttp<\/strong>.  No ?<\/p>\n
Yes, the mechanism for issuing a request on Android is not the same as Indy, but – just as with the MultipartEntityBuilder<\/strong> – it’s not exactly complicated, and in both cases it has to be done through the HTTP client object.<\/p>\n
I think it’s fair to say that if you don\u2019t know anything about it, it might take a bit of time to research it. But once you do know about it, this only takes a few minutes to write, and it works<\/em><\/strong>.<\/p>\n
Indy is Better Because Of The Bugs<\/h2>\n
Next on the hit-list is the way that Android handles a 302 redirect response (or rather, the way it doesn’t) to a POST<\/strong> request where Indy takes the redirect in it’s stride and handles it for him.<\/p>\n
Depending on the version of Indy that Mason is using, this could be an old bug in Indy.  Or, if a more recent version, he has enabled an option that restores that previous buggy behaviour.  The HTTP protocol specification stipulates that clients only automatically follow GET<\/strong> and HEAD<\/strong> 302 redirects, “MUST NOT” automatically follow them otherwise, without first confirming with the user, and should NOT change the method (to a GET).<\/p>\n
In fact, it seems that Mason is dealing with a buggy server as well since from the description of the redirect response he is expecting it sounds like it should be a 303 redirect, not a 302 at all.<\/p>\n
Mason says that his Indy code behaves exactly like a browser would.  That may be true, but perhaps only an erroneously implemented<\/em> browser, dealing with an erroneously implemented server.  \ud83d\ude09<\/p>\n
But, if you wish to implement an auto-redirect in the same way that Indy does, it should be a simple matter to do so.  See: http:\/\/stackoverflow.com\/questions\/5169468\/handling-httpclient-redirects<\/p>\n
Why Is It So Hard To Get the Response as a String !?!!<\/h2>\n
Answer: It’s Not<\/h3>\n
Finally, the issue of obtaining the response content in a string form is bemoaned.<\/p>\n
“Indy gives me the HTML<\/em>“.<\/p>\n
Well, so does Android.  Oooooh, you mean you want the HTML content in a string variable<\/em> ?<\/p>\n
Ok:<\/p>\n
\r\n    str := EntityUtils.toString(response.Entity);\r\n<\/pre>\n
Now admittedly this is bare-bones.  You should ensure that the response is valid and that there is an Entity present to convert, but this is precisely why you would put it in a convenience method if you were doing this a lot, which is all that the Indy implementation of Post() as a function returning a string does.<\/p>\n
In fact, the reason that Indy put’s the Delphi equivalent in a helper method is because without that helper method, it’s darned sight more work:<\/p>\n
\r\nvar\r\n  LResponse: TMemoryStream;\r\nbegin\r\n  LResponse := TMemoryStream.Create;\r\n  try\r\n    Post(AURL, ASource, LResponse);\r\n    LResponse.Position := 0;\r\n    Result := ReadStringAsCharset(LResponse, ResponseCharset{$IFDEF STRING_IS_ANSI}, ADestEncoding{$ENDIF});\r\n                                                                                  \r\n  finally\r\n    FreeAndNil(LResponse);\r\n  end;\r\nend;\r\n<\/pre>\n
If I had to do that every time in Android I would absolutely want to hide it all away in a helper method.<\/p>\n
But wait – that’s exactly what EntityUtils<\/strong> is, except that it is arguably a cleaner, more elegant, and more intuitive approach, providing utilities that can be used on any<\/strong> “Entity”, rather than duplicating basically identical code all over the place inside numerous wrapper methods, as is the case with Indy.<\/p>\n
Copy and Paste is undeniably one mechanism for code re-use, but it can be taken too far and has largely been replaced by Object Oriented techniques in the modern era.  \ud83d\ude09<\/p>\n
Bringing It All Together<\/h2>\n
So, let’s put everything we have so far together.  This is the complete implementation of the POSTThread.run()<\/strong> method:<\/p>\n
\r\n  method POSTThread.run; \r\n  var\r\n    http: AndroidHttpClient;\r\n    req: HttpPost;\r\n    mpe: MultipartEntityBuilder;\r\n    response: org.apache.http.HttpResponse;\r\n    s: String;\r\n  begin\r\n    http  := AndroidHttpClient.newInstance('HTTP TEST CLIENT');\r\n    req   := new HttpPost('http:\/\/posttestserver.com\/post.php');\r\n\r\n    mpe := MultipartEntityBuilder.create;\r\n    mpe.addTextBody('Username', 'test');\r\n    mpe.addTextBody('Password', 'password');\r\n    mpe.addTextBody('cmd',      'Login');\r\n\r\n    req.Entity := mpe.build;\r\n\r\n    response := http.execute(req);\r\n    s        := EntityUtils.toString(response.Entity);\r\n  end;\r\n<\/pre>\n
Actually, not quite<\/em> complete.  I have omitted the final statement which will update my UI with the response, which needs to be performed on the UI thread.<\/p>\n
Synchronize()<\/h2>\n
Just as there are many ways to achieve the objective of running some code on a background thread, there are also many ways to arrange for code to be performed on the UI thread.  What I show here is perhaps the quickest and dirtiest, being almost directly equivalent to Synchronize()<\/strong>.<\/p>\n
As if that wasn’t bad enough, I have shamelessly exploited Oxygene’s ability to fabricate such Delphi nasties as “Global Variables”, even in the Java landscape where such things are usually impossible.  In this case, I have declared a reference to my MainActivity in a global variable (Main).  This was just to save the bother of passing the reference into the thread, saving a few seconds of typing.  But this is a demo, and saving typing is what demo’s are all about, so no harm, no foul.  \ud83d\ude42<\/p>\n
So, using the reference to the MainActivity<\/strong>, I call the runOnUiThread()<\/strong> method and pass in an instance of a Runnable<\/strong> class.  Runnable, as it’s name suggest, implements a run()<\/strong> method (yes, Thread<\/strong> extends Runnable<\/strong>, but we don’t need another thread here, we just want to have a run()<\/strong> method scheduled on the existing UI Thread).<\/p>\n
I have implemented a showResponse(String) method on my MainActivity, and all I need is for my Runnable.run() method to call it.  A whole new class just to implement a one-liner override of a scaffolding method is too much like hard work, so I use an anonymous, inline class:<\/p>\n
\r\n    Main.runOnUiThread(new class Runnable(run := method\r\n                                                 begin\r\n                                                   Main.showResponse(s); \r\n                                                 end));\r\n<\/pre>\n
And there it is, done.<\/p>\n
Just for completeness, here’s the method in it’s entirety:<\/p>\n
\r\n  method POSTThread.run; \r\n  var\r\n    http: AndroidHttpClient;\r\n    req: HttpPost;\r\n    mpe: MultipartEntityBuilder;\r\n    response: org.apache.http.HttpResponse;\r\n    s: String;\r\n  begin\r\n    http  := AndroidHttpClient.newInstance('HTTP TEST CLIENT');\r\n    req   := new HttpPost('http:\/\/posttestserver.com\/post.php');\r\n\r\n    mpe := MultipartEntityBuilder.create;\r\n    mpe.addTextBody('Username', 'test');\r\n    mpe.addTextBody('Password', 'password');\r\n    mpe.addTextBody('cmd',      'Login');\r\n\r\n    req.Entity := mpe.build;\r\n\r\n    response := http.execute(req);\r\n    s        := EntityUtils.toString(response.Entity);\r\n\r\n    Main.runOnUiThread(new class Runnable(run := method\r\n                                                 begin\r\n                                                   Main.showResponse(s); \r\n                                                 end));\r\n  end;\r\n<\/pre>\n
Not that this also includes setting up the AndroidHttpClient<\/strong> (http<\/strong>), which Mason omits from his code.  The method above is everything you need to make a HTTP POST request of the required form.<\/p>\n
Redirect handling is not addressed in this example code since I didn’t have a test server to exercise that and don’t need one for my purposes (I think I could have played some more with the test POST server to create this test, but as I say, it’s not relevant to my needs.  I’ll leave Mason to try that, if he’s so inclined).<\/p>\n
And here’s a logged request<\/a> made using this code on the test server referenced in the code:<\/p>\n

\nTime: Mon, 11 Aug 14 00:55:43 -0700
\nSource ip: 27.252.213.239<\/p>\n
Headers (Some may be inserted by server)
\nREQUEST_URI = \/post.php
\nQUERY_STRING =
\nREQUEST_METHOD = POST
\nGATEWAY_INTERFACE = CGI\/1.1
\nREMOTE_PORT = 61529
\nREMOTE_ADDR = 27.252.213.239
\nHTTP_CONNECTION = close
\nHTTP_USER_AGENT = HTTP TEST CLIENT
\nHTTP_HOST = posttestserver.com
\nCONTENT_TYPE = multipart\/form-data; boundary=g6uL0L3BNb_xNFHi_tHz4jGazg-AO-tLCvUSc
\nCONTENT_LENGTH = 574
\nUNIQUE_ID = U@h2-9Bx6hIAAAzCAfgAAAAG
\nREQUEST_TIME_FLOAT = 1407743743.6923
\nREQUEST_TIME = 1407743743<\/p>\n
Post Params:
\nkey: 'Username' value: 'test'
\nkey: 'Password' value: 'password'
\nkey: 'cmd' value: 'Login'
\nEmpty post body.<\/p>\n
== Multipart File upload. ==
\nReceived 0 file(s)
\n<\/code><\/p>\n
It’s Really Not Difficult<\/h2>\n
To be clear here.  I had not tackled any<\/strong> aspect of Android networking or HTTP requests until I started looking into this 4 hours ago.  I came to this entirely “cold”.<\/p>\n
In fact, it took me as long to write this post (2 hours) as it did to reach a working example from a standing, cold start.  Quite why it took Mason 2 days and yet he still<\/em> didn’t get it working is utterly beyond me.<\/p>\n
When calling upon Stack Overflow in my research I paid attention to question and answer dates, aware that things can change and that perhaps I was coming across things that had only come to light since Mason went through this exercise.  But no, they all pre-dated his post of September 2013 (with the exception of one question dealing with MultipartEntityBuilder<\/strong>, though the class itself predates Sep 2013 by some way and there are other questions on Stack Overflow that deal with it).  He should have been able to find exactly the same information that I was working from.<\/p>\n
I should also say that it was a fortuitous coincidence that Mason should remind me (inadvertently) of his original post on an evening where investigating the development of a HTTP client was on my to do list, so I thank him for providing such a concrete framework for that investigation !  I’ve learned a lot in 2 of the last 3 hours  \ud83d\ude42<\/p>\n
But as a consequence I’m afraid I cannot agree that this is particularly difficult, unless you make it so for yourself by making assumptions and constantly seeking to achieve things in the familiar ways rather than researching the new ways that you need.<\/p>\n
I do however agree, whole-heartedly and unreservedly, when it is said about anything that if you don\u2019t know anything about it, it might take a bit of time to research it. But once you do know about it, this only takes a few minutes to write, and it works<\/em><\/strong>.<\/p>\n
\ud83d\ude42<\/p>\n
Bookends and Footnotes<\/h2>\n
One final note is that Mason’s post is bookended by questioning and then challenging the notion that using Oxygene on Android avoids having to take a “Java Pill”.<\/p>\n
In doing so he makes the common mistake of conflating a language and it’s platform\/frameworks.<\/p>\n
When I said in an earlier post of my own that this absence of Java Pill was one of the reasons I liked Oxygene, I was referring obviously to the LANGUAGE<\/strong>.  Of course you cannot avoid dealing with the Java – and Android – frameworks.  Working with the native platform frameworks is the very philosophy underpinning Elements !<\/p>\n
And with good reason: those frameworks offer a lot, if you are prepared to put the leg-work in to learning them.<\/p>\n
Once upon a time I am sure that Mason knew as little about Indy as he now does about Android, and I am sure his knowledge of Indy is the result of far more than the 2 days he spent trying to get his code working on Android.<\/p>\n
Sure, with Indy you can get a lot<\/em> of networking development done very quickly in Delphi, if you know Indy<\/strong>.  But Indy is not part of the platform API (imagine doing all this in WinSocks<\/strong>!!).  It’s not even – technically – part of Delphi.  It just comes “in the box”.  And make no mistake, Indy is not free from bugs or issues itself.<\/p>\n
And once you know the Android frameworks just as well, you can be just as productive in those.  And as a bonus there is a much wider community of developers and resources to call on for assistance and guidance than has ever been – or will ever be – the case with Indy.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 10<\/span> minutes]<\/span><\/span> Way back in September last year, Mason Wheeler blogged about his first experiences with developing for Android using Oxygene. I said at the time that I would look into reproducing his efforts and respond.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[212,205,4,180],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-A8","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2280,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2280\/","url_meta":{"origin":2240,"position":0},"title":"Oxygene Constructor Magic on Cocoa","date":"30 Aug 2014","format":false,"excerpt":"Earlier this week I mentioned that I had published my TXT-2-PARK app for Android in the Google Play Store. Today I published the iOS version to the Apple App Store (still awaiting approval at this stage). As with the Android version, I implemented the iOS version using Oxygene, and things\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1713,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1713\/","url_meta":{"origin":2240,"position":1},"title":"How to Call Java Code from an Oxygene Android Application","date":"20 Sep 2013","format":false,"excerpt":"Lachlan just posted a link to a post on Google+ (also available as a PDF) demonstrating how to call Java from Delphi XE5. I was shocked at both the amount and the nature of the code involved. It is long, convoluted and ugly stuff (nb. that isn't a criticism of\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2202,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2202\/","url_meta":{"origin":2240,"position":2},"title":"What is Hydrogene ?  Asked and Answered","date":"03 Dec 2013","format":false,"excerpt":"Over the past few weeks there has been some speculation as to what the mysterious \"Hydrogene\" that RemObjects have been working on may or may not be. Well, that particular feline has slipped it's captors and escaped the bag. I'm not aware of any official announcement and I hope that\u2026","rel":"","context":"In "Delphi"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1817,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1817\/","url_meta":{"origin":2240,"position":3},"title":"Getting the Battery Level on Android With Delphi","date":"01 Oct 2013","format":false,"excerpt":"Over the past few days I posted a two part series showing how to obtain the current battery level as part of the implementation of an Android AppWidget using Oxygene. As far as I can tell AppWidgets simply aren't possible using Delphi but reading the battery is quite straightforward Android\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":2252,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2252\/","url_meta":{"origin":2240,"position":4},"title":"Making a Noise About on a Thread","date":"13 Aug 2014","format":false,"excerpt":"I'm working on an Android app at the moment, and for a bit of fun I decided to add a startup sound to brighten the day of every user that launches it. Which gives me another opportunity to present some of the advanced language features in Oxygene that make threading\u2026","rel":"","context":"In "Android"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Audio-Resource.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":1503,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/1503\/","url_meta":{"origin":2240,"position":5},"title":"Sharing Code Across Platforms in Oxygene","date":"22 Aug 2013","format":false,"excerpt":"There seems to be a perception among some people that Delphi is in the unique position of allowing developers to share and re-use code across the various platforms that it's compiler can now (and will soon) target. But this is not the case. Oxygene has had this capability right from\u2026","rel":"","context":"In "Cooper"","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2240"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2240"}],"version-history":[{"count":11,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2240\/revisions"}],"predecessor-version":[{"id":2251,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2240\/revisions\/2251"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2240"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2240"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2240"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}