How can I encode complex objects with the multipart/form-data content type? - forms

I'm uploading a file to a POST API endpoint which has not only simple key:value pairs, but also has an array field which consists of nested elements, where one of the nested fields is the file. An example is below:
simpleField1: string,
simpleField2: int,
complexField: [
nestedField: string,
fileField: string<binary>
...
]
...
I can use the requests library similar to this post - by using the files field, we can set the multipart/form-data content type. From the docs, it seems like the file object needs to be a specific content, but the complexField consists of both binary (i.e. the file) and plain text.
How can I encode my complex field via the requests library and/or curl? Thanks!
I've tried the following, but the format seems to be rejected by the server:
files = {
'complexField': [
'nestedField': (None, 'some_value'),
'fieldField: (None, open('input.json', 'rw')
]
}
requests.post(url, files=files)

Related

Mongodb shell find to filter and extract embedded text data

I would like to find and extract details from a "stringified" api call which is a field in mongo db document.
The field is like "apiData" field below (only in one long line) which contains both request Headers and a Response Body
as an embedded object - I've separated it out on lines to make it easier to read.
The keys and values are inside "escaped" quotes
a) Can I filter/find based on a selection of header and Response body information
Currently, I'm using a regex e.g. apiData : /5684830/
Is there anything better?
b) extract a selection of header and Response body information from the field string in Mongo by
using build functionality or some else in the mongodb shell v4
Currently, I am exporting the entire field and then processing it.
I was hoping there might be a better way within the mongodb shell.
e.g Example of extract fields/end result
{
"Status Code" : "200 OK"
"numFound\": "56047",
"ebook_count_i": 14,
}
Example of document
{
_id : ObjectId("0000000000000000000000000")
apiData : {
\"Request URL\": \"http://api-call-eg.org/search.json?q=1984\"
\"Request Method\": \"GET\"
\"Status Code\": \"200 OK\"
\"Response Body\" :
{
\"numFound\": \"56047\",
\"start\": \"0\",
\"docs\": [
{
\"cover_i\": \"5684830\",
\"ebook_count_i\": 14,
\"author_name\": [ \"Rand McNally\"],
}
}
}
}
Can I filter/find based on a selection of header and Response body information
Currently, I'm using a regex e.g. apiData : /5684830/
The way you use regex is the perfect solution for the way you have stored your data
extract a selection of header and Response body information from the field string in Mongo by using build functionality or some else in the mongodb shell v4
Unfortunately, you have string. So it's the only option.
But if you can store them as field:value in mongo, you can make use of beautiful aggregation framework where you can do many queries in time efficient manner.

Same or different name for the field in a JSON-formatted input for an API that can take 2 different formats

I have an API that takes an input like
{ 'fileContent': 'base64-encoded file here' }
I would like to accept also an URI with the file content.
Should I use the same fileContent field name, for example:
{ 'fileContent': 'https://example.com/filename' }
and then decode the base64 or download the URI in my code, or use a different field name, for example:
{ 'fileUri': 'https://example.com/filename' }
Using a different field name is more flexible and makes your code less buggy when checking the field contents.

Alamofire formatting POST/PUT parameters swift

I have an issue using Alamofire on iOS (swift) :
When I try to send a request (in .POST or .PUT) with parameters like that :
parameters:["description": WhoGives, "images": (
{
container = offerImages;
name = "563f993e4b00ddad7ed42790_0.jpg";
},
{
container = offerImages;
name = "563f993e4b00ddad7ed42790_1.jpg";
}
)]
it results in a httpBody like this :
description="WhoGives"&images[][container]=“offerImages”&images[][name]=“563f993e4b00ddad7ed42790_0.jpg”&images[][container]=“ offerImages”&images[][name]=“563f993e4b00ddad7ed42790_1.jpg"
And I would like it to be :
description="WhoGives"&images[0][container]=“offerImages”&images[0][name]=“563f993e4b00ddad7ed42790_0.jpg”&images[1][container]=“ offerImages”&images[1][name]=“563f993e4b00ddad7ed42790_1.jpg"
As anyone found how to do it? And if so, how?
You will need to use a .Custom parameter encoding to do this. Since there's no RFC spec published around collection URL encoding, Alamofire uses a common convention which works for many servers, but not all.
Here's a snippet from our ParameterEncoding docs.
Since there is no published specification for how to encode collection types, the convention of appending [] to the key for array values (foo[]=1&foo[]=2), and appending the key surrounded by square brackets for nested dictionary values (foo[bar]=baz).
To implement this, you'll want to leverage the logic in the encode method for the .URL case along with the queryComponents method. You'll need to make a slight change to the queryComponents method to put the array index in the parameter value. Then you should be good to go.

Sharepoint URL to reference a lookup

I have two SharePoint lists used for Support case management. The first list contains Case Numbers and information about the case. The second list contains exhibits that support the case itself.
We have a convention that the Case Number is a String supplied by the worker, ex 20150205-001. When the exhibits are joined to the Case it is through a Lookup. I want the Exhibit ID, a String, to be of the form Case Number + _[A-Z] -- and be auto-assigned.
I want to use a Workflow (MS Sharepoint Designer 2013) to assign the Exhibit ID. The problem I face is that I cannot get the actual Case Number from the Lookup. The closest I have gotten so far is to get the ID (1, 2, etc) but not the actual String value represented.
Tried working with the following URL:
http://[mySiteURL]/_api/web/lists/getbytitle([listName])/items?$select=Title,Case/Id&$expand=Case/Id&$filter=Case/Id%20eq%2020150205%45001
substituted ascii: $filter=Case/ID eq 20150205-001
without the filter I get all list items (understandably) but the filter does not work properly because the ID is not the actual lookup value.
This is a SPD 2013 limitation. You have to use a web service call from within Designer to get the specifics of a lookup column from SharePoint. You make a REST call ad then parse the JSON response for the specific data from the lookup column. It gives you access to all of the columns from the list item that you looked up:
Build {...} Dictionary (Output to Variable: requestHeader )
Call [%Workflow Context:Current Site URL%]... HTTP web service with Variable: Request (ResponseContent to Variable: PoleIDData |ResponseHeaders to Variable: dictionary |ResponseStatusCode to Variable: responseCode )
Get d/Pole_x0020_ID from Variable: PoleIDData (Output to Variable: PoleID )
Set Name to Variable: PoleID
Your actual web service call will be formatted like this:
[%Workflow Context:Current Site URL%]/_api/web/lists/GetByTitle('List Name')/Items([%Current Item:ID%])/LookupColumnNameOnOtherList
Sorry for the formatting, I would post a screenshot but I cannot.
This article is good for showing you some of the other specifics about formatting your HTTP Request, especially the Request Headers which must be setup right.
http://www.fiechter.eu/Blog/Post/37/SharePoint-2013--HTTP-Web-Service-Action---Use-Managed-Metadata-as-Text-in-Workflow

Different types of child resources

Suppose I have to implement game character resource. Character could have only one weapon.
Weapon types are different (sword, knife, gun etc.) and have different set of properties.
Character and Weapon are separate resources for sake of usability.
In OOP model it will looks as follows
What will be the best way to design URIs and resources for such structure?
edit:
In general. Is it ok to have in Character resource link to weapon resource that return Knife, Sword or Gun or it have to be the link to certain resource such as http:\game.com\character\sword?
In general, the REST model can be mapped directly as "Object" <-> "Representation" and "OID/References" <-> "URI". So first, what you have to do is to assign each of the elements present in the game a different URI.
Option 1
Say you use JSON to describe the character, so you would have something like this:
URL: /character/Warrior
Content:
{ "name" : "Warrior", "weapon" : "/weapons/id_of_weapon" }
Note how the "weapon" includes a link (or an array of those) to the different weapons that the character has. Each of those, following the REST principle, is identified by an URI.
You have now two options to suport the type/subtype variation:
Use different MIME types
When you obtain the resource /weapons/id_of_weapon, you'll get, say, a response from the server in which the headers look like this:
HTTP/1.1 200 OK
...
Content-Type: my-game/Knife
... (more headers)
Knife data Content
This identifies the actual type of the element returned, and can be used to map it to the different subtype. You can use different schemes, such as Weapon/Knife, or MyGameObject/Weapon_Knife.
Use content-based object mapping
Also, you can explicitly set the type of the returned instance. In this case, you could get a response like this:
HTTP/1.1 200 OK
...
Content-Type: application/json
... (more headers)
{ "type" : ["Weapon", "Knife"] , ... (rest of fields) }
Note how the type JSON parameter is used as a standard in your game to specify the different types supported by that returned data.
Option 2
You may also consider, after your edit, that you can mimic the resource containment architectur in URIs. However, you propose http://whatever/character/sword. This is not appropriate, because you're naming classes, and not resources. A more appropriate URL scheme would be something like:
http://whatever/character/idc/weapon/idw
where idc and idw are the identifiers of the character and the weapon respectively. Note that you don't fix the exact type of the weapon in the resource URI (that is, you have to say weapon, not knife), but it may happen that actually the weapon with the id idw is actually of type Knife (using either of the options given above).
If you map containment to URIs, you can also have a more compact format for the character as follows:
{ "id": "idc",
"name" : "Warrior",
"weapon" : { "id": "idw", "type": "Knife", (rest of knife properties) }
}
Note how: each element has its own id. Containment is observed via JSON recursive object inclusion, you also specify the type of the weapon, and, still you can map the URL scheme just described to access the inner elements of the character.