Field validation for POST and PUT entities.

93 views
Skip to first unread message

David Antonio Jiménez Xolalpa

unread,
Oct 1, 2015, 4:03:39 PM10/1/15
to API Craft
For example an Employee entity may have the attribute "terminationDate" but that terminationDate will be null until the Employee is terminated. 

When an employee entity is posted, should the entity include "terminationDate" with a null value? Should it be optional?

And for the PUT operation, should it be required to send the null? Or if it is omitted, should the default value (null) be set? If it is not set, it may become a partial update.

I'm using Jersey with Bean Validations to build the API. First we considered that POST is not required to send that value, but PUT should. But in Java Bean Validations you cannot have an annotated resource where an attribute is sometimes validated and sometimes not. So maybe we are doing it wrong.

Mike Amundsen

unread,
Oct 1, 2015, 5:11:18 PM10/1/15
to api-...@googlegroups.com
you've got two separate problems here and it's good to NOT conflate them.

1) the interface promises you should be making
2) the internal code you need to write to honor the promises

so...
1) neither HTTP POST or PUT REQUIRE you to include any field. what drives this is how your want to frame the problem at the interface. I usually define the transitions for creation and update differently anyway (diff fields, validations, etc.) so there's no problem there. Second, I often have internal fields that are not editable for updates (IDs, critical status or date information, etc.) and dropping them from the PUT transition is the smartest way to do this. So, IME, you SHOULD NOT include fields that will always be NULL in any transition -- you're just asking for trouble<g>.

2) your code problem is a different story. if your library REQUIRES you to include NULL fields when updating, you need to put some code between accepting your POST/PUT and passing the results to your internal object model or validation code. I find most frameworks are pretty finicky about this kind of thing and are rarely useful as "direct-connections" between the interface (HTTP PUT) message and the internal object model. For this I ALWAYS write intermediaries/wrappers/translators between the external interface an the internal object code.

that's me. hope this helps.

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft.
For more options, visit https://groups.google.com/d/optout.

Kijana Woodard

unread,
Oct 2, 2015, 2:20:41 PM10/2/15
to api-...@googlegroups.com
+1 

Whenever I try to bypass those intermediaries, I regret it at some point.
Reply all
Reply to author
Forward
0 new messages