Skip to Content (Press Enter)
2018-03-08 20-43-12
Robert Chanphakeo
11Views
9Comments
Expose REST: How do I manipulate the request and the response?
Question
We would like the develoer to add additional metadata to a specific request and response with the metadata in a specific response.

I could simply create a Key/Value MetaData RecordList, and this will solve the problem however I dont want to do that, I would like the user to add their own record and values like this...into the request and it will response back with the same value.

"Metadata": {
        "InvoiceDate": "12-06-2014",
        "Priority": "High",
        "TShirtSize": "Small",
        "blah": "blah"
    }

There is no feature for me to append the metadata, i.e you can not manipulate the Exposed REST response, nor can you maniplate the Exposed REST request (other than using custom authenication, but that is not for a specific web service method!) - so how do you solve this problem?

0
0
29 Jun 2015
Copy Link
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Hi Robert,

It is indeed incredibly annoying that you can modify outgoing and incoming JSON with a consumed REST service, but not with an exposed one. Time for a new Idea I guess...
0
0
30 Jun 2015
Copy Link
2014-02-13 10-06-38
Ricardo Silva
Fear not.

The "advanced handlers" feature for Expose REST APIs did not get shipped with the first iteration, but it will come soon.

If it's not already implemented waiting to get incorporated into the 9.0.1 baseline, it should be just in the finishing brushes. João Rosado can probably answer more authoritively on this subject than me.

In any case, do you have THAT many possible fields? Wouldn't it be possible to add the possible fields as a fixed structure and simply don't send the one which aren't filled in?
0
0
30 Jun 2015
Copy Link
2018-03-08 20-43-12
Robert Chanphakeo
Ricardo, we can not define them upfront, it can not be fixed record attribute names. Meta data records are user defined fields.. these fields are defined by the user, it is used to extend /add additional information to a specific object. our app will store this user defined metadata in our database,..... and returned back to the user's app when it is requested.
0
0
01 Jul 2015
Copy Link
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Hi Ricardo,

Good to hear it's in the pipeline!
0
0
01 Jul 2015
Copy Link
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Robert,

I don't think Ricardo is talking about fixed record/attribute names. You could simply allow a list of key/value pairs as input, and store those in the database.
0
0
01 Jul 2015
Copy Link
2018-03-08 20-43-12
Robert Chanphakeo
Kilian Hekhuis wrote:
Robert,

I don't think Ricardo is talking about fixed record/attribute names. You could simply allow a list of key/value pairs as input, and store those in the database.
 Yes we could do that too, as indicated above it would solve the problem! :)

We could do this
[
   {
      "Name":"ABC",
      "Value":"111"
   },
   {
      "Name":"QRS",
      "Value":"222"
   },
   {
      "Name":"XYZ",
      "Value":"333"
   }
]

But more efficent and cleaner to do this..

   {
      "ABC":"111",
      "QRS":"222",
      "XYZ":"333"
   }
0
0
01 Jul 2015
Copy Link
2014-02-13 10-06-38
Ricardo Silva
Actually, I was meaning for Robert to use a record with fixed attribute names.

Unless you're Amazon, usually you're selling a relatively small set of item "types". For these types there will be a few attributes that are usually required. This won't be complete "wild-wild-west" with everyone having every kind of possible attributes. You'll likely have a commonly used set of attributes people want to include, like "shirt size" and the such.

At least that's how I would imagine it.

Usually I see the kind of "completely generic" solutions as sort of lazy. They show an unwillingliness to sit down with your stakeholders and make a decision on the design of your data / UI / whatever.

If the data is truly "whatever can be", perhaps the best design is what Kilian is suggesting (and Robert rejecting in the first post): a list of key-value pairs.
0
0
01 Jul 2015
Copy Link
2018-03-08 20-43-12
Robert Chanphakeo
Ricardo Silva wrote:

If the data is truly "whatever can be", perhaps the best design is what Kilian is suggesting (and Robert rejecting in the first post): a list of key-value pairs.
 I prefer efficent and clean solution
   "metadata":{
      "ABC":"111",
      "QRS":"222",
      "XYZ":"333"
   }

If your the client side/consumer web app its much easier for your app to consume this json records which you can map directly to the fixed json records in your app, than it would be use keyvalue pair array list, do a loop to find the key name you are looking for, then get it's value.

Not a real big deal but still prefer efficent and clean solution that makes the developer's life easy!  

 
 
0
0
01 Jul 2015
Copy Link
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
Ricardo,

You are right, it's best to try to define the exact types of attributes needed, and you are also right that unwillingness/lazyness on either side of the isle may be all too common with regards to this. However, if there are many different attributes and there are no obvious domains, and/or only a few attributes typically set per item, the more generic approach might be sensible.
0
0
01 Jul 2015
Copy Link
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.