Lets say I receive an xml request that is sent to my web service and this request contains some data in it such as Hotel Room/Rate pairs (Room = Double Queen, Rate = 10%). The database has all of these Room/Rate pairs stored, so when the xml request comes in, I have to validate them to see if the request contains both the room and the rate in the database. If I receive one room/rate pair and it is not in the database, I fail the message and send back an error response, but if I receive 3 room/rate pairs for example, and 2 are found in the database, but one is not, I would process the succussfull ones and send back warnings for the ones that were not found. The other scenario is if I receive 3 room/rate pair and they all are not found in the database, then I want to send back an error message. What is the best way to approach these scenarios?
2 Answers
My opinion is that you should be consistent and always follow the same path regardless of the number of data you have in the request. That way the client of your application knows what to expect. As such, being consistent leaves you only with two choices:
- strict: you are very strict and nothing goes through if you have one error (like, this is a transaction). You stop at the first error and return the response explaining where you find the first error.
- permissive: The valid rooms are successfully updated. For each room you don't have in your database, you generate a warning and continue. The response will contain a warning for each problematic data.
From what I understand it does not seem you require your request to be transactional (everything passes, or nothing) so my guess is that you may be "permissive". The client should check the warnings and do whatever it can to do better next time.
There is also a third choice, but I don't know if you can implement that into your business domain: why not "create" the missing rooms in the database if you don't have them ?
-
The rooms are created already, but if the client happens to send room="abc" when it should have been room="abc1", then we have to either send back an error basically saying the whole message failed if that was the only one or if there is more than one room and some passed and some failed, for the failed ones, they are warning and for the ones that didn't fail, they are processed successfully. Some clients want to fail everything if one room fails and some clients want to only send warning for failed rooms, but process the successful ones. In this case, the client wants to do the latter.– XaisoftCommented Sep 6, 2011 at 14:34
-
As you pointed out, permissive is the way I am going with this client. The client does try to ensure that valid data is passed through, but as you know it can't be perfect. I can't create a room in a database if it doesn't exist because then I might be creating a hotel room for a hotel that they don't even have at their hotel.– XaisoftCommented Sep 6, 2011 at 14:36
-
OK, the client can decide on that matter. Well then you could be consistent with the choice of the client :-) For example, in addition to the room data he sends a status indicating whether he wants a "transaction mode" or an "atomic mode". Depending on that status you follow either the strict or permissive path. What do you think ?– JalaynCommented Sep 6, 2011 at 14:37
-
I agree with what you are saying, but I don't have any say in this. The way the client sends the data has already been decided. By "way", I mean the format of the messages and how they are sent have been established by the client already and they are not going to change. I just have to know how to process them in code.– XaisoftCommented Sep 6, 2011 at 14:47
-
Alright, then yes you are very limited in your choices, and it seems that your only job when you detect an invalid room is to provide a meaningful error message.– JalaynCommented Sep 6, 2011 at 15:29
What you probably want to do is to incorporate success/failure in for each request in your response. So, in your example, the user would receive a response saying that the first 2 are successful and the final one failed. Bonus points for including why it failed.
-
+1: XML request is a "document". The document is either valid or not valid. One invalid thing makes the document -- as a whole -- invalid. A good error message provides details. A bad error message summarizes.– S.LottCommented Sep 6, 2011 at 15:43
-
@S.Lott, the xml document itself is not invalid, the data is invalid. <Room id="abc"></Room> is completely valid xml, but the the Room Id could be "abd" instead of "abc" which would make the data invalid.– XaisoftCommented Sep 6, 2011 at 15:51
-
@Xaisoft. The request -- represented in a document -- is invalid. The request -- as a whole -- represented in a whole document -- is invalid as a whole. The point is the "wholeness" of it. The point is that XML requests can't be subdivided because it is one document. All or nothing.– S.LottCommented Sep 6, 2011 at 15:52
-
@S.Lott, we have some clients who take the approach of All or Nothing, meaning that if one room/rate pair is invalid, do not process anything, but we have some clients who say, if 1 room/rate is invalid, but 3 are valid, process the valid ones, but send back warning message indicating which ones were invalid along with a success message for the ones that were valid.– XaisoftCommented Sep 6, 2011 at 15:59
-
(1) If you have two conflicting requirements, then don't ask which is "best". (2) This answer says which is best. If some of your clients don't like that, then they don't like what's best. (3) If you want a magical answer that resolves your conflicting requirements, please fix the question to say that you have conflicting requirements and want a magical answer. This answer says which approach is best. It's a good answer, even if you have clients that have bad requirements.– S.LottCommented Sep 6, 2011 at 16:01