| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Define canonical message/standard for REST/JSON services |
« View previous topic :: View next topic » |
| Author |
Message
|
| ruimadaleno |
 Posted: Mon Jun 22, 2015 8:56 am Post subject: Define canonical message/standard for REST/JSON services |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi all,
we're running WMB 8 providing several services to business units/applications. Those services accept and provide XML messages. These messages are transported with HTTP in SOAP envelopes (in short, there are a set of SOAP/XML web services deployed in broker).
We have defined a structure for every message that flows in and out of these set of services (inspired by the canonical message pattern).
A taste of our current standard to clarify:
Each xml message is composed of two parts: Header and Body
Header contains metadata/technical data from message (origin, who made the request, request time, guid , etc)
Body contains the business information the service needs to execute the business service.
Right now we are investigating the possibility of develop and deploy services that accept and provide JSON messages, we are talking about REST/JSON web services. The rest/Json services would be used in communications with mobile clients and maybe in API's provided to external third parties.
The challenge here is to understand if we should design a standard message format for these REST/JSON services. I believe it's a good design principle to define some rules regarding message structure: letting developers decide message structure will lead to a bunch of distinct message formats causing some complexity we want to avoid.
On the other hand, defining a standard message format can lead to "heavier" json messages and cause some limitation to developers.
So, i'd like to ear from your experiencie and get some knowledge, pointers, pitfalls, best practices on rest/json message standard/canonical message definition.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jun 22, 2015 9:26 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You need to figure out the data dependencies/requirements for each service. You can then construct specific jsons for each REST operation to meet those needs.
It would be useful to use the XML schemas you have to ensure a common data model across the JSON (so that a name field in one REST call has the same format as a name field in another).
But there's no specific reason to make all of the REST calls (at least the PUTs and GETs) use a common structure.
Just as long as they're designed from a common point of view, rather than as you say individual developers. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Wed Jun 24, 2015 5:48 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
so, let's launch some discussion 
what do you think about the following structure for REST/JSON requests:
| Code: |
{
"Header": {
"TimeStamp": "2015-06-24T11:12:46.693644",
"MessageGuid": "7cdfb07c-0042-42fc-9048-af76a269e915",
"GeneratorEntity": "ACOREANA",
"GeneratorApplication": "billingapp",
"GeneratorUser": "app_user_john"
},
"Body": {
"Bussiness_Data_Here": "data to execute business function - object array. An effort should be done to consolidate business data structures (common data model)"
}
} |
I have splitted the Json structure in two parts:
Part 1 - "Header" - Metainformation about the Json message, for monitoring, consumer billing and control.
Part 2 - "Body" - The business data needed to execute the business function. An effort should be made to consolidate the datastructures here.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 24, 2015 6:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can probably get a lot of the information you have in your header from the REST call itself, or the http request headers.
But, sure, I hope other people will discuss. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Mon Jun 29, 2015 8:12 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Also, we need to think about the capabilities delivered by broker.
I understand that some elements (like "Timestamp") can be extracted from http request header. But , if we implement this set of services in broker, and using record and replay for monitoring there is a benefit of putting these JSON message "meta-info": we can analyze/monitor the messages flowing in broker environemnt.
Let's suppose management wants to charge a fee for these REST/JSON usage. If we don't use "GeneratorEntity" nor "GeneratorApplication" (or something similar in JSON message) how can i charge users for service usage ? sure we can monitor how many requests are issued from a certain ip address. Of course a malicious user could provider a fake GeneratorEntity/GeneratorApplication.
Just some thoughts to generate discussion
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Mon Jun 29, 2015 8:50 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 364
Location: Columbus, OH
|
| ruimadaleno wrote: |
| Let's suppose management wants to charge a fee for these REST/JSON usage. If we don't use "GeneratorEntity" nor "GeneratorApplication" (or something similar in JSON message) how can i charge users for service usage ? sure we can monitor how many requests are issued from a certain ip address. Of course a malicious user could provider a fake GeneratorEntity/GeneratorApplication. |
Is there any sort of authentication or authorization being done for these calls?
We use Datapower as a web service gateway and callers to web services must have a username and password to call a service. After they are authenticated (username/password ok) we then check to see if they are authorized to call the particular operation (SOAP) or resource (REST) they are trying to access.
Each application has it's own username/password so it is easy to track who is calling what and preventing unauthorized users from calling what they shouldn't. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 29, 2015 9:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You could also use some kind of oath/api token, which could be tracked through the whole stack.(or at least up to a certain point) |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
