0

I was testing a service response, (same service same operation different parameters).

When searched by birth date one of the returned results was let's say client id = "CID1234".

So I searched again but this time by client id = "CID1234", same service same operation but this returned no result.

When I raised the issue I was told that client search by Id only returns active clients and that is consistent with observed results.

Somehow I think there must be an equivalent to conservation of energy, there should be conservation of data/information. A record within a same service-operation can not both exist and not exist at the same time depending on the query parameter, as if it was a SQL query for sure it wouldn't make sense, it would break some rule that I can not think what it might be called.

I am including SQL tag because I know for sure if this was a sql query then this situation would not happen, but I do not know why, just that we have always taken it for granted with SQL, can SOA be different?

jimjim
  • 2,414
  • 2
  • 26
  • 46
  • You need to be more specific. It appears that you're using strings, such as `'CID1234'`. Or do you mean that the field `CID` contains the integer value `1234`? And if you're using strings, be careful of whitespace; the following values are Not the same... `'CID1234'`, '`CID 1234'`, `'CID1234 '` – MatBailie Dec 19 '16 at 06:02

2 Answers2

0

As a dba i would describe as a flaw in the business logic. However it really depends upon how the developer intended the API to be used.

It may simply have been overlooked, or it could be intentional for privacy or security reasons. Or simply just wasnt required.

The scenario you describe sounds a bit inconsistent, but if that was the requirement given to the developer, and it meets the requirement they did thier job.

Just because you think it could or should work differently or better doesnt make it wrong.

Sir Swears-a-lot
  • 402
  • 7
  • 20
  • Lets say if this was at Database level and direct SQL quarries behaved like this, then it would be considered a bug, the question is why that is a bug? what requirement of lambda calculus is broken – jimjim Dec 19 '16 at 05:42
0

It isn't a technical or architectural thing -it is a business decision whether a search can return results of inactive account and/or whether or not you can't retrieve an inactive account.

That said, you can get to such situation when an account was active at the time of request 1 and became inactive by the time of request 2. though I would expect a result from request 2 saying the account is inactive

Arnon Rotem-Gal-Oz
  • 25,469
  • 3
  • 45
  • 68
  • No, it not about timing, if a record is quarried by value of it's fields, then it is retrieved, if iti is quarried by value of some other field then it is not retrieved, Business decision to make things inconsistent is not a valid excuse. Either the record is active and can be accessed by any of it's fields values or it is inactive and can not retrieved by any of the fields values. It is inconsistent unaccepted behaviour. – jimjim Jan 21 '17 at 10:04
  • I am saying the business decision is one way or the other (i.e. either you don't display inactive or you do) I agree the API should be consistent – Arnon Rotem-Gal-Oz Jan 21 '17 at 10:14