For now multipart data is not explicitly supported in yaas. But you can follow the tutorial to use it in your microservice. But I met a small problem in using it. What I expected is there is only one post method is automatically generated in the default resource file, which only has one final YaasAwareParameters yaasAware parameter. But actually there is anotherpost method which also need a application/json part as the post body.

2.PNG

Let’s double check our api.raml file and you can see we only accept the multipart as the post body. How could the wrong method be generated?

3.PNG

Actually this is quite a tricky problem. The second is automatically generated because of the 23th row in the last screenshot. When you say the type of an endpoint is collection, then it will be treated like a normal entity and a new data could be posted into the collection via application/json format.

Easy way to solve this problem is just remove this line. Before doing mvn clean install don’t forget to remove theunnecessary post method in your default resource file. Then you will see everything is ok now.

But as we know the rules endpoint is truly a collection, why no problem occurred after the type line is removed? Because when we invoke the get method to query the rules collection, the collection is returned in an entity, and the entity could be transformed into a collection like List<Rule> list = response.readEntity(List.class);

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Daniel Roth

    Hi Cong,

    My name is Daniel Roth and I’m with SAP Hybris, working on the team, that is responsible for the Service SDK. Your findings are correct on why you got that second endpoint. But to shed more light in the dark I want to give an explanation on how the application/json ended up there.

    Since you created an endpoint /rules of type collection, the endpoint automatically inherited methods defined in the collection pattern: https://api.yaas.io/patterns/v1/resource-type-collection.yaml. As you can see there, a post method on the endpoint is defined, that expects application/json as content-type. That this didn’t gave you an error, I assume, that you additionally have a schema of type Rule, that is then therefore used as parameter in that method.

    There are currently only two options available for you:

    • You just keep everything as is and change the implementation to throw a java.ws.rs.NotSupportedException in order to notify the user that you don’t support that media type. That way you can keep the type of the endpoint as ’collection’, but your contract would still reflect, that your API supports the application/json content type.
    • Second is just to remove the type collection, as you found out yourself already, so this side effect is not reflected in your generated sources, but that leaves you to write the desired methods for that resource yourself.

    Best,

    Daniel

    (0) 

Leave a Reply