I've been trying out Retrofit and I really it's simplicity.
However I have an otimization concern.
I'm using Parse for my backend and it has a pure Rest API.
When I want to update an object I use a PUT HTTP Request and pass in the body only the specific values I want to update.
However, using Retrofit I always have to serialize the entire object when passing it using the #Body annotation. If I have a very large object, this is very inneficient.
All the solutions I see is using Annotations to inform the Converter which fields are exposed. However this affects all requests and won't work if I have different update methods for updating different fields.
I think I have two options:
Pass the parameters I want to update as Form parameters and use
the #URLEncoded annotation. However this is not really RESTful
and I don't think Parse supports it.
Create an annotation to inform which fields should be added to JSON in the body. For doing this, how can I access the method's annotations in the Converter, in order to select which fields to serialize?
Retrofit uses Gson by default. And Gson excludes null values by default. So it shouldn't be a problem (unless you are using primitive types in your object)
Related
I am trying to implement REST query param "fields" with Mapstruct. The REST "fields" query param by convention lets you specify as its value a comma separated list of the fields of the entity you want in the response when you are preforming a GET request on an entity. This is opposed to returning all the fields of entity, which is what happens when "fields" query parameter is omitted.
Example:
GET locahost/blah/1
Response {"a":"1", "b":"2", c:"3"}
GET local/blah/1?fields=a,c
Response {"a":"1", "c":"3"}
So what I want Mapstruct to do is only map the bean's fields who's fields' names I specify. Note I need to be able to specify the bean's fields' names I want to map at runtime. Why? The fields I wish to map change from call to call of the GET method.
From what I read in the MapStruct documentation, you can specify what fields to map or not map with annotations. Unfortunately you can't change the annotation value at runtime (It maybe possible through reflection, but it feels should be a better way).
Given what I want to do, does anyone know how I can specify at runtime what fields are mapped?
Or alternately does anyone know a better way of implementing the REST "fields" query param?
I Look forward to reading the responses. If you have any questions or need clarifications just ask 🙂.
Regards,
Ben.
Thinking about this, I think that it doesn't make sense. As MapStruct generates the mapper classes at build time and therefore can't changing the mapping process at runtime. Is this right?
Currently, we are exploring CodeEffects for our one of the rule engine proposal.
We have a dynamic type which is a JSON string. During runtime, we need to apply the rule for JSON using CodeEffects. Is it support for FlexSource or any other possibility.
You need to serialize your Json string into a .NET object, fill it with data if needed, and pass that object to the Evaluator together with your rule for evaluation. The FlexSource is designed specifically to support this kind of scenarios. Download the FlexSource demo project from Code Effects website and replace the XML data file used there as the source object with your Json.
I am working on new API, but I am stuck with the choice for enabling Projection support.
my Entity User contains some properties and have some relationships too.
What should be the preferred approach for API?
Approach1
myApi.com/User/Fields="Id,Name,Email"
it returns my UserDTO with just populating Id,Name,Email and rest properties are null (I can further ignore the null before serializing JSON to send over the wire)
Approach2
myApi.com/User/GetCustomPropertiesABC"
it returns my UserCustomABCDTO . This Model contains just three properties for Id, Name, Email.
My question
I personally feel Approach 1 gives more Reuse quotient to API, Every time new selector required in Approach 2 will need to create a New DTO, But what is standard as per REST principles?
well, you could use ODATA for this, it would be perfect for it actually : http://www.odata.org/
Or, you could create an endpoint which accepts a request like your Approach 1 and returns dynamic. This way you don't have to worry about creating DTOs, you just create a new dynamic object, add whatever properties are required and return just that.
This keeps the returned entity small as it avoids who knows how many null or empty properties which don't really add anything useful.
Based on the recommendation by APIGEE in their RESTful API Design blog post I wish to implement the fields query-string parameter to allow mobile application clients to restrict the content returned from a single RESTful API call. For example:
domain.site.com/rest/accounts/{id}?fields=name,id,age
If the fields parameter is omitted then a complete account resource will be returned. My question is how would I implement this on the server using Jersey (for example). Since Jersey makes it easy to return an Account POJO but I am unsure how to restrict the fields of the resulting JSON object based on the 'fields' query-string parameter.
There's not an automatic way to do it. Your service should load the entire object and then null out the fields you dont' want. Make sure the beans are annotated to ignore null fields in the json serialization and then return the object after you've modified it to remove the fields you dont' want.
I am working on a web application which is being developed using GWT. I am also using OWL ontologies and Jena framework to structure semantic contents in the application.
A simple function in the application would be getting some data from the user and send it to the servers side to be stored as a data graph using the ontology. I suppose one way would be to store the data as java class objects equivalent to the ontology classes and send them using the GWT async communication. To convert OWL classes to java, I used Jastor.
My question is that after the server receives the java class, is it possible to easily convert is to an OWL individual and add it to the data graph, using the functions of Jena and/or Jastor? For instance in the server side interface implementation we call something like this:
Public void StoreUser (User userObj) {
//User: a Jastor created java class. userObj is instantiated using the user data on the client side.
OntModel ontModel = ModelFactory.createOntologyModel(OntModelSpec.OWL_DL_MEM);
//Open the ontology here using inputstream and ontModel.read!
Individual indiv = (Individual) userObj.resource();
//Add the individual to the model here! }
Unfortunately I wasn't able to find any Jena function that can add an existing individual to the model.
Would you suggest another way to pass the ontology data to server side and store it, rather than using Jastor created classes (for instance using an XML file)?
Thanks for your help
There are two parts to the answer. First, an Individual is a sub-class of a Jena Resource, which is definitely something that you can add to a model. However, individual resources, or properties or literals are not stored in a Model. A Model stores only triples, represented as Statement objects in the Java API. So to add some resource to a model, you have to include it in a triple.
In Jena, an individual is defined as a subject of a triple whose predicate is rdf:type and whose object is not one of the built-in language classes. So if you have:
ex:my_car rdf:type ex:Ferrari .
ex:Ferrari rdf:type owl:Class .
(note: this example is entirely fictitious!), then ex:my_car would be an individual, but ex:Ferrari would not (because OWL Class is a built-in type). So, to add your individual to your model, you just need to assert that it is of some type. Since I don't know GWT and don't use Jastor, I can't say whether the type association that is normally part of a Jena Individual is retained after serialization. I suspect not, in which case you'll need to have some other means of determining the type of the individual you want to add, or use a different predicate than rdf:type to add the resource to the the Model.
All that said, personally I probably wouldn't solve your problem this way at all. Typically, when I'm working with client-side representations of server-side RDF, I send just the minimal information (e.g. URI and label) to the client as JSON. If I need any more data on a given resource, I either send it along with the initial JSON serialization, or it's just an Ajax call away. But, as I say, I don't use GWT so that advice may not be of any use to you.