I have a REST service wich uses hypermedias with siren content.
To be useable, the client have to send a Accept header with this value :
application/vnd.siren+json
But when i virtualize this service via Centrasite to the Mediator package, requests are rejected.
When i use an accept with only application/json requests are accepted but the content is without hypermedias links, so it is not useable.
I have changed the content-types.xml file in resources of package Mediator like that :
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<content-types xmlns="http://contentTypes.mediator.softwareag">
<!-- Please enter the custom content-types
<content-type type="xml">
<name></name>
</content-type>
-->
<content-type type="json">
<name>application/vnd.siren+json</name>
</content-type>
</content-types>
With that, requests with siren are now accepted, but without hypermedias content (as with application/json)
How can i force Mediator to accept this accept header and tranfer it to the endpoint without changing it ?
I use a webMethods Integration Server 9.7 with IS_9.7_Core_Fix19 and a Mediator 9.7.0.0017-0490
Update :
After viewing endpoint logs, it seems that the header and the response are correct, but the response is truncated by mediator.
All the siren content is removed from the json response, but the response is still well formed, but incomplete, without any log in Mediator even in Debug mode.
Is it a Mediator problem, an axis one, or anything else ?
Aftere searching in Empower knowledge base, I've found this :
If the Content-Type header field specifies a content type for which no content
handler has been registered, Integration Server uses the default content
handler (ContentHandler_Default), which treats the content as text/html.
This explains why I have to change the content-types.xml file in the config directory of the WmMediator package.
Secondly, I've found that issue :
SMGME-6616 (Fix 18)
MultiRoot node elements of JSON type are not passed for a custom content type.
When a custom content type for JSON is executed and a multi root node
element is passed as a request for virtual rest API, then only the first
node is passed to the backend native API. This issue is resolved.
This seems a good explanation why I don't have the full content of my response, because with the Siren Hypermedia format, we have multiple roots in the json message.
So, no solution except patching.
Edit:
After patching, the problem is resolved
Related
I am trying to publish a json message using the Amazonsns connector in WSO2 ESB 4.9. I am able to successfully publish a simple string message however when I set the messagestructure to json in order to send different messages to different platforms and attempting to send json as the value of message it will not work. I am using a simple transaction that looks almost exactly like the documentation sample. My Transaction:
content-type: application/json;charset=UTF-8
{
"region":"us-west-2",
"accessKeyId":"MyAccessKey",
"secretAccessKey":"MySecretAccessKey",
"version":"",
"messageStructure":"json",
"subject":"Test",
"message": {"default":"mess","email":"message"},
"targetArn":"arn:aws:sns:us-west-2:977102061874:endpoint/APNS_SANDBOX/mobile_iOS_Sandbox/34ed4324e6-1119-67sd-b7dd-f413c88e4e25",
"topicArn":""
}
My result is an unexpected error sending message out.
Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,73]Message: Illegal character: <d>
My service is also like the example:
<amazonsns.init>
<region>{$ctx:region}</region>
<accessKeyId>{$ctx:accessKeyId}</accessKeyId>
<secretAccessKey>{$ctx:secretAccessKey}</secretAccessKey>
<version>{$ctx:version}</version>
</amazonsns.init>
<amazonsns.publish>
<message>{$ctx:message}</message>
<subject>{$ctx:subject}</subject>
<messageStructure>{$ctx:messageStructure}</messageStructure>
<topicArn>{$ctx:topicArn}</topicArn>
<targetArn>{$ctx:targetArn}</targetArn>
</amazonsns.publish>
I did not expect much success but just started trying different things....I attempted xml encoding the json message and get the same message on '&'. Using wire logs I found the content type of the successful messages going to Amazon were application/x-www-form-urlencoded so I also tried url encoding and get same message on the '%'.
I'm running out of ideas. I double checked the connector documentation to make sure I did not miss anything. It does say you can use a JSON transaction for Publish and gives a sample transaction however it does not discuss anything special/different that you would need to set up in order to make this work. Is there something I am missing?
UPDATE: Can see it is using the Builder for application/x-www-form-urlencoded which is stumbling on the json. Have tried setting messageType and ContentType properties to application/json. JSON Builder is enabled. It just seems the connector wants to send it out as application/x-www-form-urlencoded, is there something I am not setting properly to tell the connector this is JSON?
UPDATE: The publish template that comes with the connector is setting the messagetype to applicaiton/x-www-form-urlencoded which is overriding any of the settings I am making in my proxy service. Going to look at changing the template in the connector to use a different messagetype and/or allow me to set it in the proxy dynamically then will be trying again.
Joe
We have created a public JIRA for this issue. Please follow that.
You need to enable message builders for the content types you are sending. make sure following is done.
Enable relevent Message builder for each content-type.
< messageBuilder contentType="application/json"
class="org.apache.synapse.commons.json.JsonStreamBuilder"/>
Make sure Content-Type header property is parsing with the message.
Make sure your Json is wellformed.
I'm using Django REST Framework and all the API calls come from Android and iOS apps. The system works perfectly most of the time, however, when an internal server error happens and I get an email from Django, the POST of the WSGIRequest contains <could not parse> instead of the actual posted JSON data (even though 'CONTENT_TYPE': 'application/json' is also in the header, and the data is sent as JSON).
This is really annoying, as it would be great to see the request body that actually causes the error, not just the stacktrace.
The <could not parse> part is very similar to this question (in the ModPythonRequest part): django request.POST contains <could not parse>, except the actual problem is slightly different. Also the reference link in that question (https://stackoverflow.com/questions/12471661/mod-python-could-not-parse-the-django-post-request-for-blackberry-and-some-andro) seems to have gone down, even though the name looked very promising.
I'm on Django 1.6.2 and DRF 2.3.13.
The POST dictionary of the WSGIRequest is always going to be invalid, because it is intended to hold the parsed form data when the Content-Type is application/x-www-form-urlencoded or multipart/form-data.
The data you want is in the body attribute of the WSGIRequest object, which isn't output when that object is converted to a string to be written to the log.
When using Django REST framework, you will typically want to access request.DATA (which will handle whatever formats you have parsers configured for - defaulting to form content and JSON) instead of Django's standard request.POST, which will only handle form encoded data.
I have WSO2 API Manager configured and everything seems to work fine.
The only issues bothering me is that in case of an Auth exception, the API manager always returns the response with XML content type, e.g.,
<ams:fault xmlns:ams="http://wso2.org/apimanager/security"><ams:code>900904</ams:code><ams:message>Access Token Inactive</ams:message><ams:description>Access failure for API: /exchange, version: 1.0 with key: 1139a466ebfd825aca953ad7259b9f45</ams:description></ams:fault>
In case of client communicates with my web service with JSON format, the XML response will look a little bit strange.
Is there any ideas how to make API Manager provide error response in JSON format?
This has been addressed in recent versions of API Manager. Auth errors can be set to json format by adding or updating the error_message_type property in WSO2HOME/repository/deployment/server/synapse-configs/default/sequences/_auth_failure_handler_.xml:
<property name="error_message_type" value="application/json"/>
I've found this also requires JSONBuilder and JSONMessageFormatter to be selected for the json content type in axis2.xml (which is the default setting).
For older versions, this article explains how to manually do the same.
Hi (Sorry for my english),
I would be use the new tools windows : REST Client in PHPStorm 6, but i have a little problem.
I write my soap url and it's ok, i retrieve the xml response (look at Heberger image http://img15.hostingpics.net/thumbs/mini_529269screen1.png).
After that i want call the method : login but i don't see how that work, how pass this method to the rest api. (look at Heberger image http://img15.hostingpics.net/thumbs/mini_696499screen2.png)
And the xml response was :
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>Sender</faultcode><faultstring>Invalid XML</faultstring></SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
Thank you for your response (and correction on my bad english :( )
Judging the response your service uses SOAP, why this client is tailored for REST. Take a look at Representational state transfer (REST) and Simple Object Access Protocol (SOAP) to get the difference.
Basically to perform the request you need to provide a properly formatted request body (which may be quite elaborate).
The Sun Cloud API at http://kenai.com/projects/suncloudapis/pages/Home is a good example to follow for a RESTful API. True to RESTful principles, when you GET a resource you get no more nor less than a representation of that resource.
The Content-Type header in the response tells you exactly what the type of that resource is, for example application/vnd.com.sun.cloud.Snapshot+json. Sun has registered these mimetypes with the IANA.
How practical is this in general currently? Most API's I have seen have used the Content-Type of "application/json". This tells you that the response is JSON but nothing more about it. You have to have something in the JSON object, like a "type" property, to know what it is.
I'm designing a RESTful API (which will not be made public, therefore I wouldn't be registering mimetypes). I have been using RESTEasy and I find that even if I specify a complete mimetype, the Content-Type in the response header will be exactly what the Accept request header specified. If the request asks for "application/*+json" by default the response header will have "application/*+json". I can probably fix this by changing the header before the response goes out, but should I try to do that? Or should the response have a wildcard just like the request did?
Or should I just serve up "application/json" like most APIs seem to do?
Additional thoughts added later:
Another way of stating the question is: Should I use HTTP as the protocol, or should I use HTTP only as a transport mechanism to wrap my own protocol?
To use HTTP as the protocol, the entity body of the response contains the representation of the object requested (or the representation of an error message object), the "Content-Type" header contains the exact type of the object, and the "Status" header contains a success or error code.
To use HTTP as merely a transport mechanism, the "Status" header is always set to 200 OK, the "Content-Type" is something generic like "application/json", and the entity body contains something that itself has an object, an object type, an error code and whatever else you want. If your own protocol is RESTful, then the whole scheme is RESTful. (HTTP is a RESTful protocol but not the only possible one.)
Your own protocol will be opaque to all the transport layers. If you use HTTP as the protocol, all the transport layers will understand it and may do things you don't want; for instance a browser will intercept a "401 Unauthorized" response and put up a login dialog, even if you want to handle it yourself.
I use my own vnd.mycompany.mymediatype+xml media types for many of my representations. On the client I dispatch to the appropriate controller class based on the media type of the returned representation. This really allows the server to control the behavior of my client application in response to the user following a link.
Personally, I believe that using application/xml and application/json are one of the worst choices you can make if you hoping to support REST clients. The only exception to this is when the client only uses downloaded code (like Javascript) to interpret the data.
Or should I just serve up "application/json" like most APIs seem to do?
I don't think so.
A media type is the only point of coupling between your RESTful web application and the clients that use it. The documentation of your media types is the documentation of your API. Your media types are the contract between your clients and your application. Eliminate the specific media type and you eliminate an important element that makes REST workable.
Sun has registered these mimetypes with the IANA.
Couldn't find any mention of that here. AFAIK, there is no requirement to actually register your custom media type with the IANA. The convention seems to be to use the inverted domain notation of application/vnd.com.example.app.foo+json, which prevents namespace conflicts. If and when your media type becomes stable and public, it might be a good idea, but there's no requirement. Could be wrong on this, though.
Will you get any value by specifying a complete mimetype? Would you do anything with the complete mimetype different than you would if the mimetype was application/json?
My 2 cents- If the API is not going to be made public, then I see no reason for a complete mimetype. A mimetype of application/json should be more than enough. You already know the type of json that the response is returning. If the API eventually becomes public, then worry about a complete mimetype... or just let people figure it out.