Let's suppose i'm dealing with 3 (very) different messages formats inside my Mule ESB, i'll call them A, B and C. They could be XML (via socket), some custom text-format and SOAP transporting another kind of XML (it's not the same that is transported via socket), for example. All of them can be transformed into each other. A, B and C carry the same information, only in different formats.
Each one of them will have it's own entry point in the flow, some format validations etc..
But, there's some (a lot) of logic that i need to be executed in all of them like dealing/extracting some information, routing based in the content, enriching etc etc..
What should i do? I mean, i did some research on integration patterns but didn't found anything about this situation or similar.
The easier approach sounds like taking one of the formats (let's take B) as the "default" one of my "main-flow" and implementing all the common logic based on it. Then, every message that arrives will be transformed to B and then transformed again to the destination format, even if the two points uses the same format.
Examples:
1) One "A" hit my app, then it's transformed to "B" to execute the common-logic, then it's transformed again to "A" to be delivered.
2) One "C" hit my app, then it's transformed to "B" to execute the common-logic, then it's transformed to "A" to be delivered.
Then, my question is, does Mule have a feature that provides me a better way on doing something like this or the solution above looks reasonable?
Thanks in advance.
The are a few options, any of these can be implemented in Mule. The first two are close to what you have suggested.
Normalizer: http://eaipatterns.com/Normalizer.html
Canonical Data Model: http://eaipatterns.com/CanonicalDataModel.html
Routing slip: http://eaipatterns.com/RoutingTable.html
Envelope: http://eaipatterns.com/EnvelopeWrapper.html
Which you use will depend on your messages and what you need to do with them.
With Canonical Data Model for example you could build a seperate flow for each incoming type that:
Receives a object in their own format.
Translates that object to the canonical object.
Passes that message on to the main processing flow.
The main flow would only need to know how to process that object.
Any endpoints that need the original object back would sit behind a transformer that can reverses the transformation.
You could pick one of your existing objects and use message variables to remember the original format or create a new object that remembers the original type itself.
Related
I've written a presentational component (https://github.com/studioraygun/react-dropdown-list) but now I want to use it in another project I've hit a stumbling block.
I want a show a list of data which comes from an API but the data is formatted very differently to what the component expects. I think I have two options:
1) Write a sub-component which lets me generate the actual list using the map function
2) Find a way to "alias" or rename the array keys being sent by the API
Neither approach feels ideal, and I wondered if there might be a more sensible way?
I have java library that runs webservices and these return a response in XML. The webservices all revolve around giving a list of details about items. Recently, changes were made to allow the services to return JSON by simply converting the XML to JSON. When looking at the responses, I saw they're not as easy to parse as I thought. For example, a webservice that returns details about items.
If there are no items, the returned JSON is as follows:
{"ItemResponse":""}
If there is 1 item, the response is as follows (now itemResponse has a object as value instead of a string):
{"ItemResponse":{"Items":{"Name":"Item1","Cost":"$5"}}}
If there two or more items, the response is (now items has an array as value instead of an object):
{"ItemResponse":{"Items":[{"Name":"Item1","Cost":"$5"},{"Name":"Item2","Cost":"$3"}]}}
To parse these you need several if/else which I think are clunky.
Would it be an improvement if the responses were:
0 items: []
1 item: [{"Name":"Item1","Cost":"$5"}]
2 items: [{"Name":"Item1","Cost":"$5"},{"Name":"Item2","Cost":"$3"}]
This way there is always an array, and it contains the itemdata. An extra wrapper object is possible:
0 items: {"Items":[]}
1 item: {"Items":[{"Name":"Item1","Cost":"$5"}]}
2 items: {"Items":[{"Name":"Item1","Cost":"$5"},{"Name":"Item2","Cost":"$3"}]}
I'm not experienced in JSON so my question is, if you were a developer having to use these webservices, how would you expect the JSON resonse to be formatted? Is it better to always return a consistent array, even if there are no items or is this usually not important? Or is an array not enough and do you really expect a wrapper object around the array?
What are conventions/standards regarding this?
Don't switch result types, always return an array if there are more items possible. Do not mix, for 1 item an object for more an array. That's not a good idea.
Another best practise is that you should version your API. Use something like yoursite.com/api/v1/endpoint. If you don't do this and you change the response of your API. All your client apps will break. So keep this in mind together with documentation. (I've seen this happen a lot in the past..)
As a developer I personally like your second approach, but again it's a preference. There is no standard for this.
There are several reasons to use json:
much more dense and compact: thus data sent is less
in javascript you can directly access those properties without parsing anything. this means you could convert it into an object read the attributes (often used for AJAX)
also in java you usually don't need to parse the json by yourself - there are several nice libs like www.json.org/java/index.html
if you need to know how json is build ... use google ... there tons of infos.
To your actual questions:
for webservices you often could choose between xml and json as a "consumer" try:
https://maps.googleapis.com/maps/api/place/textsearch/json
and
https://maps.googleapis.com/maps/api/place/textsearch/xml
there is no need to format json visually - is it not meant for reading like xml
if your response doesn't have a result, json-service often still is giving a response text - look again at the upper google map links - those are including a response status which makes sense as it is a service.
Nevertheless it's the question if it is worth converting from xml to json if there isn't a specific requirement. As Dieter mentioned: it depends on who is already using this service and how they are consumed ... which means the surrounding environment is very important.
So I have a theoretical question based on a lot of research that I have done recently with regards to REST API interfaces.
Firstly I understand that in REST, resources should be nouns and not verbs and each resource should be decoupled from the next resource, however the resources can return the same entities or collection of entities, depending on the purpose of the resource.
My focus however is performing restful search.
In all the research I have done, the most common solution I have come across is the use of parameters in the URL
api.test.com/search-cars?param1=val1¶m2=val2
Now while this is standard practice and is not truly breaking the rules of REST, why is it that no one represents the search parameters as an id (possibly in the form of JSON)
api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
If I look at cars as a resource and represent my id as a JSON, I could easily say that I truly have a finite number of cars thus a finite and unique number of id's.
Further more this promotes pure rest by conforming to "resource/id"
What are the benefits and downsides to using parameters as in the first example?
What are the benefits and downsides to using JSON as an id with the "filters" as in the second example?
All your comments would be really helpful as I need to take a final decision on how to move forward with the first resource of my API. Also, I need to have a strong argument for my boss explaining why I decided on either of the methods.
The general form of an URL is
scheme://domain:port/path?query_string#fragment_id
So you propose two URLs:
search by query_string
search by last path segment
Search by query_string
I recommend to name the collection cars, not search-cars. As you write in your question, URLs identify resources. The cars resource identifies the collection of all cars. I have no idea what collection a resource called search-cars would identify.
GET http://api.test.com/cars
would return the collection of all cars.
GET http://api.test.com/cars/123
would return the car identified by 123.
GET http://api.test.com/cars?color=blue&year=2013
would return the collection of all blue cars build in 2013.
Search by path
Your second URL
GET http://api.test.com/cars/{"color":"blue","year":"2013","make":"toyota"}
would make the query (JSON) a part of the path. To make the two examples equal, I suppose to make the JSON a query parameter:
GET http://api.test.com/cars?search={"color":"blue","year":"2013","make":"toyota"}
JSON vs. named query parameters
Most REST frameworks support mapping of query params to method parameters.
Most REST frameworks allow you to map a path segment to a method parameter. And, again, most REST frameworks allow you to map JSON to an object or a simple dictionary.
What makes JSON harder to use is the need to escape the "{} characters:
{"color":"blue","year":"2013","make":"toyota"}
becomes
%7B%22color%22%3A%22blue%22%2C%22year%22%3A%222013%22%2C%22make%22%3A%22toyota%22%7D
which is not very nice.
Summary
You can use both the query_string and the path of the URL to identify a resource. Search parameters are better placed in the query_string because the ? can mentally be translated to the WHERE of SQL.
Don't use JSON in URLs because escaped JSON is hard to read.
I have a rest web service api, and I have a lot of stats that are aggregates of child data in an object. Where should I nest these stats? I thought about making them a resource all of their own, but it would mean a huge number of requests, instead of including them in a single json response.
For example:
GET /data
game:{
level: 1,
events:[
{event:...}
]
total_events: 23,
avg_events: 3
}
Or should things like total_events be within the events object?
I haven't found any good examples of how to this.
I'm not entirely sure I understand your intentions, but I would nevertheless put such aggregate information in the parent resource, along with the listing of child URLs.
If the child link list is too much trouble to build and the client is often only interested in the statistics, then you could introduce an extra query parameter to switch between the available respresentation formats. (e.g. "stats_only", "links", or "full".)
I'm attempting to move an existing (and working) client-side jQuery validation schema to JSONSchema to allow myself to validate arbitrary JSON on both the client and server.
My application is essentially a bunch of gigantic forms with lots of complex logic determining which questions should be asked based on the user's response to other questions. The forms each have over 200 fields.
Right now I'm only doing client-side validation and that works well about 99% of the time. Browser issues have cropped up on a few occasions, but nothing catastrophic. That being said, I want to do server-side validation (!).
After reading the JSONSchema draft and browsing around some of the v3 implementations, it seems like I might lose some of the more complex rules that my application has come to depend upon. I want to be sure that I'm not missing something before moving too far in any direction.
Some examples:
"If x == 10, then y is required, otherwise it's optional"
10 could be a literal value, an enum, etc., but I need to be able to reference another field in the same structure and guarantee it's value not only exists, but is equivalent to a specific type / value.
I think this is addressed in this thread on the JSONSchema list.
"If x = today's date, and y = tomorrow's date, then x > y"
This logic will be used to ensure that the "from" date comes before the "to" date.
From what I can see there's nothing like this and the only way I can see doing it is passing in a freshly eval-ed chunk of JSON as the schema.
The closest thing I've found to meet the above needs is CERNY.
If I'm barking up the wrong tree, please let me know. I'm also looked into running backbone.js on both the client and server.
tl;dr;
I want to maintain one set of validation rules for large and complex forms and apply these validation rules to arbitrary JSON documents on both the client and server side.
there is many tricks but not all of them are possible. For example
if x == 10 then y is required can be achieved with something like (draft 3):
"type":[
{"properties":{"x":{"enum":[10]}, "y":{"required":true}}},
{"properties":{"x":{"disallow":[{"enum":[10]}]}}}
]
Let's say, it's possible but very tricky… a schema is basically supposed to validate the structure, not it's content (even if there is few properties for this)
Another possible way I personally do like is to "extend" the current validation graph with an external url based schema. The idea is to send parameters of the current document on an url which one will return a relevant schema according to those parameters.
Example:
{
"extends":{"$ref":"http://checkCustomValidity/{x}/{y}/"};
}
Where at "runtime" the schema sent back could be a {"disallow":"any"} if not allowed or {} if ok
This is useful as the url can be both used for the client and server side (your client will not be completely standalone but in some cases, you just cannot)
A real life usage for this is in cases where it is obliged to use a remote service. For example if I do have to check if my nickname is already used on the server during the registration. I code a server side web service answering to the request path: http://www.server.com/isNicknameUsed/{nickname}