For a PHP application I am integrating a REST service capable of receiving multiple nested HTTP requests at once. This is identical to the google calendar API: https://developers.google.com/google-apps/calendar/batch
However, I am not sure about the best way to parse this single request into multiple requests. The request to the server (from the Google example) would look like this:
POST /batch HTTP/1.1 Authorization: Bearer your_auth_token Host: host Content-Type: multipart/mixed; boundary=batch_foobarbaz Content-Length: total_content_length --batch_foobarbaz Content-Type: application/http Content-ID: <item1:[email protected]> GET /farm/v1/animals/pony --batch_foobarbaz Content-Type: application/http Content-ID: <item2:[email protected]> PUT /farm/v1/animals/sheep Content-Type: application/json Content-Length: part_content_length If-Match: "etag/sheep" { "animalName": "sheep", "animalAge": "5" "peltColor": "green", } --batch_foobarbaz The top section (above --batch_foobarbaz) should be available in the $_SERVER I presume. For the nested requests I clearly cannot use that.
My current action plan would be:
- Create a
requestclass with properties for each header - Create a
requestparsing class that parses each singlerequestobject - For the
/batchrequests a wrapper would be used that splits the batch into multiple smallerrequestobjects, feeding them from the extracted nested requests. - For all normal/single requests it would simply populate the
requestwith data from the headers. Both nested and single requests would then be handled the same through therequestparsing class.
The splitting of the request would be done using an explode() on the boundary. But then? Parse each section using regular expressions to get every key:value? And expect the payload to be wrapped in newlines? Or is there some function / class available that would do this for me?
Any suggestions on how to tackle this is greatly appreciated. The response would also be a multipart/mixed message with responses per request. That way each single request would still use the REST principles.
