• 0 Posts
  • 299 Comments
Joined 1 year ago
cake
Cake day: June 20th, 2023

help-circle
  • If it’s part of the Requirements that the frontend should handle “No results found” differently from “Not authorized”, even if that’s just by showing an icon, then ach list of stuff which might or not be authorized should have a flag signalling that.

    (This is simply data analysis - if certain information is supposed to be shown to the user it should come from somewhere and hence the frontend must get it from somewhere, and the frontend code trying to “deduce it” from data it gets is generally prone to the kind of problem you just got because unless explicitly agreed and documented, sooner or later some deduction done by one team is not going to match what the other team is doing. Generally it’s safer just to explicitly pass that info in a field for that purpose to avoid frontend-backend integration issues).

    Authorization logic is almost always a responsibility of the backend (for various reasons, including proper security practices) and for the frontend it’s generally irrelevant why it’s authorized or not, unless you have to somehow display per-list the reason for a it being authorized or not, which would be a strange UI design IMHO - generally there’s but a flag in the main part of the UI and a separate page/screen with detailed authorization information - if the user really wants to dig down into the “why” - which would be using different API call just to fill in that page/screen.

    So if indeed it is required that the frontend knows if an empty result is due to “Not Authorized” rather than “No results found” (a not uncommon design, though generally a good UI design practice is to simply not even give the user access to listing things the user is not authorized to see rather than let the user chose them and then telling them they’re not authorized to do it, as the latter design is more frustrating for users) that info should be an explicit entry in what comes from the backend.

    The JSON is indeed different in both cases, but if handled correctly it shouldn’t matter.

    That said, IMHO, if all those 3 fields in your example should be present, the backend should be putting a list on all 3 fields even if for some the list is empty, rather than a null in some - it doesn’t matter what the JSON is since even at the Java backend level, a List variable with a “null” is not the same as a List variable with a List of length 0 - null vs empty list is quite a common source of mistakes even within the code of just the one tier, though worse if it ends up in API data.

    Who is wrong or right ultimately depends on the API design having marked those fields as mandatory or optional.


  • That sounds like an error in the specification of the client-server API or an erroneous implementation on the server side for the last version: nothing should be signaled via presence or absence of fields when using JSON exactly because, as I described in my last post, the standard with JSON is that stuff that is not present should be ignore (i.e. it has no meaning at all) for backwards compatibility, which breaks if all of the sudden presence or absence are treated as having meaning.

    Frankly that there isn’t a specific field signalling authorized/not-authorized leads me to believe that whomever has designed that API isn’t exactly experienced at that level of software design: authorization information should be explicit, not implicit, otherwise you end up with people checking for not-in-spec side effects like you did exactly for that reason (i.e. “is the no data being returned because of user not authorized or because there was indeed no data to retunr?”), which is prone to break since not being properly part of the spec means any of the teams working on it might interpret things differently and/or change them at any moment.


  • If I remember it correctly, per the JSON definition when a key is present but not expected it should be ignored.

    The reason for that is to maintain compatibility between versions: it should be possible to add more entries to the data and yet old versions of the software that consumes that data should still continue to operate if all the data they’re designed to handle is still there and still in the correct format.

    Sure, that’s not a problem in the blessed world of web-based frontends where the user browser just pulls the client code from the server so frontend and backend are always in synch, but is a problem for all other kinds of frontend out there where the life-cycle of the client application and the server one are different - good luck getting all your users to update their mobile apps or whatever whenever you want to add functionality (and hence data in client-server comms) to that system.

    (Comms API compatibility is actually one of the big problems in client-server systems development)

    So it sounds like an issue with the way your JavaScript library handles JSON or your own implementation not handling per-spec the presence of data which you don’t use.

    Granted, if the server side dev only makes stuff for your frontend, then he or she needs not be an asshole about it and can be more accomodating. If however that data also has to serve other clients, then I’m afraid you’re the one in the wrong since you’re demanding that the backwards compatibility from the JSON spec itself is not used by anybody else - which as I pointed out is a massive problem when you can’t guarantee that all client apps get updated as soon as the server gets updated - because you couldn’t be arsed to do your implementation correctly.






  • Not in the EU it doesn’t, unless they got the user to review that Agreement and agree before the sale took place.

    After the implicit contract which is the sale has been agreed to by both parties (the buyer gave the money, the seller took it), one of the parties can’t force the other party to agree to a new contract before they’re allowed to get the contractual benefits of the original contract (i.e. the buyer getting to use the product they bought, the seller getting to use the money they got).

    It doesn’t matter if the seller has such power de facto - legally they most definitelly can’t blackmail the buyer by denying them their side of the contractual rights they got in the Act of Sale by blocking their use of the product they bought until they agree to a new Agreement from the seller.


  • It’s my impression that it’s actually a lot more about national pride for Spain than about Gibraltar’s fiscal paradise status, since Gibraltar as not part of a member country can just be treated the same as any other offshore fiscal paradise, such as the Bahamas, which includes it being added to black lists. In this day and age, it’s not geographical proximity that matters when it comes to fiscal paradises.

    This makes sense since Britain too doesn’t really gain much from having possession of Gibraltar so holding on to it is mainly a question of national pride for the UK - it would be strange if Spain’s motivations were wildly different.

    PS: Also it’s funny how during the Leave campaign a lot of the “reason” why the EU would give Britain quasi-membership rights (without the responsabilities) after leaving the EU were a lot like this, about how those other countries or interests inside those countries would do it because they stood to gain monetarilly from it in the short term. All that turned out to be mainly wishful thinking and a serious misreading of the motivations of the leaders and people in said other countries.

    Just found it funny how there are still people around thinking other countries are mainly motivated by the short term gains in sovereignty affairs, even whilst Britain itself again and again keeps doing things motivated by national pride when it comes to such affairs - one would’ve expected that “they’re a lot like us” would somehow been figured out by now.


  • I’m sorry but the UK is the entity we’re talking about, not actual persons - individuals can’t join or leave the EU on their own hence it’s the actions of the actual formal nation state that get judged when it comes to joining or leaving the EU.

    Consider the possibility that it’s your nationalist feelings (and given the huge role of British Nationalism in Brexit that’s not actually a good thing) that are making you confuse the country and the actions of it by the hand of it’s elective representatives, with you yourself and people like you - the actions of the nation never really represent all people in that nation and it’s not really healthy (IMHO) to identify yourself with The Nation.

    People being critical of a country seldom means they’re critical of everybody in that country, unless they’re nationalist far-right morons, in which case their problem is a lot bigger than merely talking in an acerbic way about a nation.







  • I’ve lived in a couple of countries of Europe, including the UK whilst it was an EU Member.

    The spirit about the EU in the UK was always different, no “stronger as a group” mindset, always “what’s in it for me” and trying scheme after scheme to see if they could swindle the rest of the EU.

    Then on top of it all there were all the many insults to the EU - and by extention the people in it - during the Leave Referendum and even afterwards, coming from amongst others top people in party in government, including the PM.

    I remember how even the Remainers were running around with delusions of national superiority: for example one of their arguments were “We should stay and change the EU from the inside”, as if Brits knew better what the EU should be than the other 470 million people in it.

    The EU doesn’t really need that kind of member nation, more so when we’re dealing with another one like that in our midst: Hungary.

    Respect is earned, not due, and the UK has a lot of work ahead to earn it.