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"?

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.

I am happy that you are working on it.

Regarding the use-case, it's now simply not possible to stub these kind of services in outsystems for example.

Well, it's a start :). Is there anything in the works to make the distinction between attributes sent or not sent?

Really glad to hear about that :)

Looking forward for the next updates!

Kilian, we have released in Technical Preview to gather feedback in order to help us to shape PATCH end-state fully coping with underlying semantics. So at this stage just receiving feedback.

Hi Kilian Hekhuis,

Were you able to implement the SCIM API with Outsystems? I have the same challenge in one of our projects and would like to know if you were able to do it and how.

Thanks in advance for your time time and wisdom

Hi Adelino,

Please restrict posts here that pertain to the Idea, questions can be asked in the forum.

Hi All,

Just wanted to mention that REST Expose PATCH has released in GA in Feb 2023 (release notes). Although the implemented solution does not fully comply with HTTP PATCH verb semantics, we were focused mainly focused on unblocking use cases where PATCH was mandatory, like SCIM, and supporting all REST Expose HTTP verbs. 

Feel free to start using it and please convey feedback through the feedback button directly from Service Studio.