Shared model objects across integration response models in apigateway - amazon-web-services

Say I have 2 response models A and B. A and B shared a common nested object C. (ie A.C.field1 B.C.field1).
As I understand APIGateway today I must define C in the model definition for A and then again for B.
This results in two undesirable outcomes:
Totally duplicated json schema (annoying but not impossible to manage).
In the generated obj-c (or java) SDK I have two distinct classes A.C and B.C. This duplication complicates use of the SDK as the two version of C are not the same type.

You can define your shared model object and refer to it in other models with a canonical reference.
Assuming you've defined a common model "C", you could refer to model "C" in models A or B with the following JSON schema:
Model A or B:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"type": "object",
"properties": {
"field": {
"$ref": "https://apigateway.amazonaws.com/restapis/{{api-id}}/models/C"
}
}
}
The generated SDKs will have a common object C.
If your shared object properties are contained to a single Model, you can use an inline reference instead:
{
"$schema": "http://json-schema.org/draft-04/schema#",
"definitions": {
"C": {
"type": "object",
"properties": {
...
}
}
},
"type": "object",
"properties": {
"field": { "$ref": "#/definitions/C" },
...
}
}

Related

In Loopback.js, how to query on embedded models?

I'm using MongoDB connector and have a Considerate and Discussion model setup like this:
model-config.json:
{
"Considerate": {"dataSource": "db"},
"Discussion": {"dataSource": "transient"}
}
considerate.json:
{
"name": "Considerate",
"base": "PersistedModel",
"relations": {
"discussion": {"type": "embedsOne", "model": "Discussion"}
}
}
discussion.json:
{
"name": "Discussion",
"base": "Model",
"properties": {
"name": {"type": "string"}
},
"relations": {
"considerate": {"type": "belongsTo", "model": "Considerate"}
}
}
}
How can I query for Considerates based on Discussion's properties? For example, something like this:
Considerate.find({where: {'discussion.name': 'snow white'}})
Inspecting Mongo persisted data, I see that in each Considerate document, there's a _discussion property. Consequently, Considerate.find({where: {'_discussion.name': 'snow white'}}) works. However, this is undocumented and wondering if there is a documented/reliable way to to this.
You can use the filters in the REST APIs wherever you want data from your relations. Eg: [include][relationName]
I think you can also pass data to the fields here.
https://docs.strongloop.com/display/public/LB/Where+filter
This might help you too
https://github.com/strongloop/loopback/issues/517

Recommended pattern to implement global Search with multiple Objects type (Ember 2 + JSONAPI)

I am new to Ember and I will like to implement a server side search endpoint that returns results for several models/tables in DB.
Trying to figure out what is the best practice to do this in Ember.
Server results can contain several types of objects/models, each model is already defined in ember-data.
So far I am able to retrieve the results (I can see the results in ember-inspector) but I am not able to render it properly (I only have access to first object for some reason).
Current architecture:
rails-5 server with JSONAPI response
ember 2.3 with multiple models
Flow:
POST /search with body:
{"search":{"query": "xxx","size": "10"}}
RESULT:
{
"data": [
{
"id": "111111",
"type": "foo",
"attributes": {
"x": "y"
}
},
{
"id": "222222",
"type": "bar",
"attributes": {
"z": "y"
}
}
]
}

How to form Hypermedia for Groups and Lists

I am designing a REST API and in this particular use case, trying to figure out the best way and what this hypermedia should look like.
The scenario is that the caller calls /persons?fields=lastName;filter=beginsWith=b because he wants back a list of people whos last names begin with "b".
Below shows the JSON response that I'm trying to figure out how best to mold/represent including hypermedia to associate with.
You can see a list of persons and you only see the name property because it's a partial representation of each person.
Then I try to add HATEAOS in here but not sure what would be the most useful to add and really what that should reference.
I figured ok, I can provide a href to the group (list) itself that I'm returning here. And if that's the case, where? I don't think it makes sense to put it in a root object like I'm doing. Because the expectation is to return a list of people, not also some root meta object so it doesn't feel good to me on what I have below.
OR
Does anyone think it isn't useful or not really embracing the HATEOS in this particular instance and I should instead provide some other type of href links in here?
JSON - List of person objects (representations) returned
[
"meta": {
"rel": "self",
"href": "http://ourdomain.api/persons?fields=lastName;filter=beginsWith=b"
},
{
"name": {
"last": "best"
}
},
{
"name": {
"last": "bettler"
}
},
{
"name": {
"last": "brown"
}
}
]
well, it is really your choice here, but I think that if you exclude a representation from navigability (i.e. not providing links to it) then it isn't HATEOAS anymore (just my opinion here).
In my opinion you could do something along the lines of the json you provided in the question, just separate clearly what is the result of the call and what is meta-information :
{
"meta": {
"rel": "self",
"href": "http://ourdomain.api/persons?fields=lastName;filter=beginsWith=b"
},
"resource" : [
{
"name": {
"last": "best"
}
},
{
"name": {
"last": "bettler"
}
},
{
"name": {
"last": "brown"
}
}
]
}
which is not so uncommon. Another approach would be to provide links to the list in every resource you return, with a relation like parent or source (maybe source makes more sense as it is a filtered query), e.g.
{[
{ "name" : {
"last" : "best"
},
"meta": {
"rel": "source",
"href": "http://ourdomain.api/persons?fields=lastName;filter=beginsWith=b"
}
},
{ ..and so on.. }
]}
after all, the list is just a container for the results, so it would feel more 'clean' (at least to me) not to have any hypermedia in it.

How to define mapping for all future field in elastic search

I am using template on elasticsearch 1.1.1 which is creating special mapping at index creation.
My template is as following :
{
"template": "*",
"mappings": {
"foo": {
"properties": {
"where": {
"type": "nested",
"properties": {
"*": {
"index": "not_analyzed"
},
"geo_point": {
"type": "geo_point"
}
}
}
}
}
}
}
There will be future fields in the nested object "where". I would like them to not be analyzed to avoid tokenization during a terms Faceting. Unfortunately I do not know the name of this future fields when my index is created.
Do you know any way of defining a mapping for any future field in a nested or inner object ?
Sincerely,
You can use dynamic templates for this, along with the index template that you already posted. Have a look here.
You can specify patterns that match your fields and have mappings apply to them instead of the usual defaults.

Ember V1.0.0-pre.2: capitalization in handlebars templates

We are using Ember V1.0.0-pre.2 and our handlebars is as follows:
{{#each data.Product}}
<div>
{{Details.uid}} - {{Details.Name}}
</div>
{{/each}}
Our the 'data' bit is from this json:
{
"Product": [
{
"Details": {
"uid": "1",
"Name": "one"
}
},
{
"Details": {
"uid": "2",
"Name": "two"
}
},
{
"Details": {
"uid": "3",
"Name": "three"
}
},
{
"Details": {
"uid": "4",
"Name": "four"
}
},
{
"Details": {
"uid": "5",
"Name": "five"
}
}
]
}
This fails with the following warning:
WARNING: Watching an undefined global, Ember expects watched globals to be setup by the time the run loop is flushed, check for typos
When I change Details.whatever to details.whatever the warning disappears.
Is this by design or can we get around it somehow? The data is returned from the server in a fixed format and we wouldn't want to use another interim model if we can avoid it.
Ember has a naming policy where "instances/attributes" always start with a lowercase letter whilst "classes" always start with an uppercase letter. I think that's probably where you are running into some issues, if possible you should be de-serialising your JSON into attributes starting with lowercase letters.
Relevant part pulled from the guides (http://emberjs.com/guides/object-model/classes-and-instances/):
By convention, properties or variables that hold classes are capitalized, while instances are not. So, for example, the variable Person would contain a class, while person would contain an instance (usually of the Person class). You should stick to these naming conventions in your Ember applications.
Naming convention apply also to model data, but if you can't change what is coming from your API you can get around this by defining a map on a per property basis, e.g.
App.Adapter.map('App.Product', {
details: {key: 'Details'},
name: {key: 'Name'},
fooBar: {key: 'FOO_BaR'}
...
});
see here for more reference on how to map your json to your models: https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/mixins/mappable.js
hope it helps