Status: Open
Status: Answered
Status: Closed
Status: Duplicate

REST API and JSON

0
Posted Mar 23 by Brandon Lucas.

Is it possible to send REST requests in as JSON format instead of plain text body data? Everything returns in JSON, and it would seem we would be able to request in JSON as well but I see no references to it.

14 Answers

0
BEST ANSWER: As chosen by the author.

Please check out the API references elsewhere on this site. Also, you can see in our Content Server Sample App that we post JSON to the Content Server REST APIs. Here is a code snippet from that app:

/* 
    ajax call to <base url>/cs/api/v1/nodes,
    to create a folder.  Need to pass type, parent_id, name, description 
    as parameters in the data section.
*/
$.ajax({
    type: "POST",
    url: content.BASE_URL + '/nodes',
    dataType: "json",
    data: { type: 0, parent_id: nodeId, name: folderName, description: folderDesc},
    beforeSend: function( xhr ) {
        // Add the otagtoken header
        xhr.setRequestHeader( "otagtoken", content.otagtoken ),
        xhr.overrideMimeType( "application/x-www-form-urlencoded" )
    },
    success: function (data) {
        ...             
    },
    error: function(jqXHR, textStatus, errorThrown) {
        ...
    }
}

For more details, see [this article](/awd/resources/articles/1501648/appworks+demo+app+for+content+server "Content Server Demo").


0
BEST ANSWER: As chosen by the author.

So, unless I'm missing something obvious, shouldn't this work?

enter image description here


0
BEST ANSWER: As chosen by the author.

Any ideas?


0
BEST ANSWER: As chosen by the author.

Sorry for the delay, Brandon. I am following this up with the team.


0
BEST ANSWER: As chosen by the author.

No problem.. will await your response.


1
BEST ANSWER: As chosen by the author.

Unfortunately, there is an internal CS limitation, which does not allow using the content type application/json for POST and PUT request payloads. The only useful content types for structured data are application/x-www-form-urlencoded and multipart/form-data.

If you have a JSON object literal with flat properties - it is the case of the most CS REST API calls - you can use Werner's example and don't care of the actual content type; just pass the object to $.ajax and let it use the form encoding:

var parameters = {username: 'testusername', password: 'testpassword'};
// Pass the parameters form encoded
$.post(content.BASE_URL + '/auth', parameters);

Content-Type: application/x-www-form-urlencoded

username=testusername&password=testpassword

If you have a JSON object with nested properties to send - when creating a new node with category attributes, for example - you would need to use a trick. The CS REST API looks for the parameter called body. If it is sent, it is supposed to contain the request parameters as stringified JSON object. You can have it form-encoded by jQuery:

var parameters = {name: 'New Folder', description: 'A folder', parent_id: 2000, type: 0};
var data = { body: JSON.stringify(parameters) };
$.post(content.BASE_URL + '/nodes', data);

Content-Type: application/x-www-form-urlencoded

body=%7B%22name%22%3A%22New%20Folder%22%2C%22description%22%3A%22A%20folder%22%2C%22parent_id%22%3A2000%2C%22type%22%3A0%7D

If you want to send a file content too, you would use the multi-part MIME encoding:

var parameters = {name: 'New Folder', description: 'A folder', parent_id: 2000, type: 0};
var formData = new FormData();
formData.append('body', JSON.stringify(parameters));
$.post(content.BASE_URL + '/nodes', formData);

Content-Type:multipart/form-data; boundary=----WebKitFormBoundarypXHXhPoib4iYMVYd

------WebKitFormBoundarypXHXhPoib4iYMVYd
Content-Disposition: form-data; name="body"

{"name":"New Folder","description":"A folder","parent_id":2000,"type":0}
------WebKitFormBoundarypXHXhPoib4iYMVYd--

The body-trick does not work for /auth; it works for the other POST and PUT calls.


0
BEST ANSWER: As chosen by the author.

You weren't kidding when you said internal CS limitations. I just traced it with fiddler and builder. if you send your data with application/json, it never even makes it to the request record within the request handler. At first, I thought maybe something was being stripped out of the request. I now think that the cs.exe in OTHome/cgi is simply not able to process any JSON payload encoded this way. If the data did make it into the request handler's request record, it would be possible to extend the restAPI request handler to do any missing massaging.<br/>
-Hugh


0
BEST ANSWER: As chosen by the author.

:-) You're correct that it's the limitation of the CGI executable. (And of the ISAPI filter and of the Java servlet too.) They pre-parse the response and recognize textual and file parameters to pass them to the OScript. Only the URL-encoded form and the multipart MIME formats are recognized. JSON is "just a garbage" for the current implementation :-) The OScript part of the request handler comes to late; the fix has to be done in the C part.

There is a feature request to fully support the application/json for request bodies, but the feature list for the next CS version has become so long, that this one will fall back to the backlog, I'm afraid. The workaround for the clients was "too easy" ;-)


0
BEST ANSWER: As chosen by the author.

Hi Ferdinand,
grabbing information from this thread, in order to fix the issue on plain Content Server, I crafted a very simple java Filter to be used with LLServlet. The filter basically creates this ficticious "body" parameter out form the request body, I guess a similar approach has been used in app-gataway, when proxing CS rest services.
My question is: as far as you know there is any chance OT is going to integrate some kind of similar enhancement, at least for LLServlet, any time soon ?


0
BEST ANSWER: As chosen by the author.

Wow! That's taking the initiative. Thanks, Patrick!

I think that the final solution, which OT will implement, will not be introducing an additional servlet filter, but modifying the processing in the current servlet to consume the JSON content type too. Anyway, that's technical and it's not what decides when this would be fixed.

Technically, making the change will not be a big problem, but from the business point of view, other feature requests of paying customers may keep this functionality in the backlog for quite a while. This actually makes your solution nice workaround for anyone, who uses the CS servlet and doesn't want to wait for moths before OT implements it. That's me too, actually :-) I run my development CS with Tomcat on Linux.

Would you mind sharing your servlet filter with the others on your blog or here? Thank you!


0
BEST ANSWER: As chosen by the author.

Hi Ferdinand,
I have just uploaded the Filter at the following address: http://blog.answermodules.com/content-server-rest-services-2-handling-forms/ you might be also interested in the post itself.
Cheers


0
BEST ANSWER: As chosen by the author.

Hello,

Is there any new infomration regarding support of POST JSON body to Content Server?
Currently this is very restrictive not to send JSON content custom REST service.

Fixed in 10.5?

Thank you in advance.


0
BEST ANSWER: As chosen by the author.

I am afraid, that I haven't heard about any change made or planned in the CS regarding this issue.

Patrick's filter shows a promising workaround. You could review it. I find the code promising with the following remarks:

  • uuencode the JSON payload to the body parameter
  • change the request content type to application/x-www-form-urlencoded

0
BEST ANSWER: As chosen by the author.

Thank you for response.

Patrick's workaround expects Java application server. My current system do not use java component on http side.
I am afraid that such workaround is not the best solution for such common need.

What can community do to convince OT to support JSON body for rest services?
I think there are some more other integrators who are eager for that possibility.

Regards,
keit


 You have subscribed and will receive email notifications of updates to this topic. To unsubscribe, uncheck the checkbox.

Statistics

Your answer

To leave an answer, please sign in.