12
 Followers
59
 Likes

REST expose: allow PATCH and indicate which fields have been sent

Integration
On our radar

It is possible to consume a REST API using the PATCH method, but it isn't possible to expose a REST API with it. PATCH is meant for selectively updating data (instead of all at once, like PUT). I would like the Platform to support PATCH for an exposed REST API as well.

However, PATCH is useless without being able to detect which fields (Attributes) have been sent by the calling party. Currently, if a consuming party doesn't send all the fields, the Platform will set them to the default value. This works for most cases, but not for a PATCH. Therefore, when supporting PATCH, there must be some way (via a runtime property) for the Platform to indicate which fields have been sent, and which were not.

Created on 19 Jul 2018
Comments (22)
Merged this idea with 'Add HTTP method 'Patch' for exposing REST api methods' (created on 27 Jun 2018 06:39:30 by Stefan Dirkx)

For now the only available values are: Get, Post, Put and Delete



This comment was:
- originally posted on idea 'Add HTTP method 'Patch' for exposing REST api methods' (created on 27 Jun 2018 by Stefan Dirkx)
- merged to idea 'REST expose: allow PATCH and indicate which fields have been sent' on 23 Oct 2018 15:06:37 by Kilian Hekhuis

Hi Stefan,


Can you detail your use case to use PATCH in an exposed REST API? Thanks!



This comment was:
- originally posted on idea 'Add HTTP method 'Patch' for exposing REST api methods' (created on 27 Jun 2018 by Stefan Dirkx)
- merged to idea 'REST expose: allow PATCH and indicate which fields have been sent' on 23 Oct 2018 15:06:37 by Kilian Hekhuis

Changed the category to Integration




This comment was:
- originally posted on idea 'Add HTTP method 'Patch' for exposing REST api methods' (created on 27 Jun 2018 by Stefan Dirkx)
- merged to idea 'REST expose: allow PATCH and indicate which fields have been sent' on 23 Oct 2018 15:06:37 by Kilian Hekhuis

André,

For an use case, please take a look at the accepted answer here:

https://stackoverflow.com/questions/47921841/rest-api-update-single-field-of-resource



This comment was:
- originally posted on idea 'Add HTTP method 'Patch' for exposing REST api methods' (created on 27 Jun 2018 by Stefan Dirkx)
- merged to idea 'REST expose: allow PATCH and indicate which fields have been sent' on 23 Oct 2018 15:06:37 by Kilian Hekhuis

A must have... Please, implement patch

How is this still marked as new? :D 

Please implement PATCH. André, as an example, I cannot implement a SCIM client because it uses patch - http://www.simplecloud.info/

Please consider enabling this. 

We don't need to waste time asking for specific scenarios as http protocol includes this for a long time. Http protocol have a specification, blocking us to adhere to it is the answer. We don't need a specific scenario.

Just don't block us to use what is correct if we know what we are doing.

On consumed apis OS supports PATCH and the dropdown list includes it. Why should you block it on exposed?

To don't block on very specific use cases just include PATCH on drop-down for verb on exposed method, ignore or split suggestions based on a fragile specification or the case of fields suggested by Kilian.

 I think PATCH was first on RFC-5789, https://tools.ietf.org/html/rfc5789 in 2010.

Do we have any updates on this? Very much required.

Hi All,

As Kilian has specified in the initial idea, "PATCH is useless without being able to detect which fields (Attributes) have been sent by the calling party". Also, this is assuming that you are exposing an OutSystems entity, how often to you expose an OutSystems entity? Most probably you are not exposing a plain entity with all the foreign keys, etc. You are doing some database query (aggregate or SQL) and expose the result set. 

So how are you suggesting the Patch method would work, which kind of structure would be as the input parameter? Would be able to have multiple input parameters?

I'm trying to understand how you see this would work on the platform if you can add a real example would be wonderful.


Thanks,

Hi Moitinho,


To be honest, just not blocking the PATCH command in IIS would already be a gain! In my scenario - to support SCIM - the payload of a PATCH is already different than a PUT: it's made up of operations so I could support that right away!

In any case, without introducing NULLs in the language, one way would be indeed some sort of extra "skipped" parameter. This parameter could be as simple as just a json where any field/attribute in a (real) parameter that was not specified would show up explicitly in this skipped parameter. For example if the PATCH had a parameter Struc with Attr1 and Attr2, the action could have

MyPATCHAction

-> StrucParm (InParm)

---> Attr1 = "My name"

---> Attr2 = "" (unknown if specified or not unless you look into StructParmSkipped below)

-> StructParmSkipped (InParm) 

{
    "StrucParm": {
       "Attr2": "skipped"
    }
}

Default for attributes not appearing in StructParmSkipped would be "specified".


Another (possibly better) option would be for this json to be returned in a system action that the implementation of PATCH would call in case it wanted to have this info (similar to NofifyGetMessage() ).

Hi Fernando,

"this is assuming that you are exposing an OutSystems entity" - I'm a bit at loss what you mean here. This is not about OutSystems Entities, but about resources. PATCH is a partial update of a resource. This resource might map to an OutSystems entity, or several, or to some other data outside the OutSystems database, but that's not important - what's important is that in case of a PATCH the caller only sends part of the full data set, and only those parts should be updated.

So if the input data for a POST would look like this:

{
  "Name":"Mr. Bean",
  "Age":"56",
  "Country":"England"
}

(and most likely the input for a PUT as well), if I were to send a PATCH with the following data:

{
  "Name":"Rowan Atkinson"
}

Only the name must be updated, but not the other attributes. Currently, in the latter case the OutSystems app sees the Input Structure as if this was sent (assuming default default attributes):

{
  "Name":"Rowan Atkinson",
  "Age":"0",
  "Country":""
}

so it cannot safely determine what Attributes were sent or not. A simple run-time attribute of an Attribute would fix this, e.g.

User.Age.IsSpecified


Thanks for your quick response.

In both (Miguel and Kilian) your approach I can see that either using Patch or Put the caller need to sent extra data stating what has changed, due to the fact that in OutSystems we need to have a fixed structure as input parameter, if we could have a generic JSON as input parameter there would be no need to specify the extra information (StructParmSkipped or User.Age.IsSpecified).


How this would be different than having a list of key-value pair structure as an input parameter? Similar to your suggestion still need to handle some processing on the exposed action, however, the developer will only have to deal with the values that have changed.



Hi Moitinho,

The idea was for the sender NOT to have to send anything else but the payload they would normally send. To use Kilian´s example, If the record would normally be

{
  "Name":"Mr. Bean",
  "Age":"56",
  "Country":"England"
}

and they wanted to not send Age, they would just send

{
  "Name":"Mr. Bean",
  "Country":"England"
}

On the OutSystems input, of course Age attribute would be there (with value zero). 

OutSystems would build up the "specified" extra info before arriving at the PATCH service action. Upon calling PatchGetSpecified() it would return something like

{
  "Name":"specified",
  "Age":"skipped",
  "Country":"specified"
}

or simply

{
  "Age":"skipped"
}


Indeed, Fernando, if that is your takeaway from what I wrote, you need to read it again, closely. Miguel gets it perfectly. Note that I'm not advocating for anything that's specific to OutSystems (other than detecting what has changed), I just described how PATCH is supposed to work in REST (de facto, there's no de jure way, and in fact, PUT may be used for partial updates instead of PATCH, but exactly the same method could be used).

I agree. Good Idea

Just to make this idea visible again, when will we get this so we can build truely restfull api's

Thanks, Daniël for your message.

We are actively looking into this use case. I cannot make any promises at this stage but can assure you that is something that we are considering.

Hi Fernando,

If you're actively looking into it, perhaps change the status from "New" to "On our radar"?

Changed the status to
On our radar


Thanks Kilian, just did.

I know it is on the radar, but I also just bumped into the fact that OutSystems doesn't support this. So just wanted to add my vote to improve the creation of truly RESTful api's.

views
1508
Followers
12