We have been receiving a 500 error when attempting to retrieve attachments from the demonstrator system. It has taken a while to track down the problem, but it appears that the A005 returns a url of Binary/19eb7224-df3-4730-a5cb-67eac811f1a5.
When querying for attachments, this url gives a 500 error. You CAN get a response for A006, but not with that url. The A006 url that works is c5d2d200-7613-4a69-9c5f-1bb68e04b8d8, but that is not what is provided from A005. These used to be linked, but it appears that when you changed from the legacy ids (att-70000-70001) to the UUID format, the link was broken. Having these disconnected is very inconvenient. Is it possible that the demonstrator system could be updated to be properly linked as it used to be?
Thank you for raising this with us, as you suspected there does appear to have been a change in behaviour when we updated the sandbox examples to use UUIDs rather than the legacy IDs.
As stated in the Environments and testing section the sandbox is only suitable for early developer education and testing and is very limited in its functionality. The implementation is entirely stateless, the sandbox simply replies with a fixed response given a supported input. The sandbox is not backed by a real instance of the e-RS system - it is just a stub implementation.
To keep the sandbox simple we do not guarantee consistency (of IDs, state, etc.) across API endpoints.
If you are looking at exercising multiple endpoints in combination then we advise this is done in the “Integration test” environment, this environment uses an instance of the real e-RS system which will behave in the same way as the production system (and is consistent and stateful).
I will raise a ticket on our side highlighting the change in behaviour, we may choose to address this but I can’t give any guarantees. As stated above you should make use of the “Integration test” environment for this type of testing.
