• bvs23bkv33 (unregistered)

    this is some best practices we need to implement

    product we use has only 2 (two) users around the world and instead of REST/SOAP uses FML (field manipulation language, but it is what you thought frist)

  • (nodebb)

    Well. That set of APIs definitely put the C in JSON.

  • (nodebb)

    My APIs which perform data updates always have a request boolean field called "performUpdate", which indicates whether the update should be performed.

  • scriptninja (github)

    nb4 someone else points out that by some (most?) standards the RESTful update should be a put, not a post. Unless they did while I was typing.

    I speak not from self-righteous snootiness but from intellectual interest. The webservices my deparment maintains range from sad SOAP to relatively recent and well-done REST, but certainly include worse than this.

    ("sad SOAP" is what sprang to mind as a term for SOAP services that take and return serialized objects as payloads, with no guidance outside the source code as to what they should look like, in order to avoid figuring out how to create a more descriptive WSDL.)

  • (nodebb)

    This is because many parts of "Enterprise" software are typically outsourced to companies that employ people who are still in school, earning degrees in how to copy/paste code from Slashdot

  • Anon (unregistered) in reply to scriptninja

    I, too, have encountered something similar to what you call 'sad SOAP'. A soap service where the method calls required you to pass parameters that were essentially objects serialized into XML, and which returned strings that were, of course, XML that required deserializing back into objects.

    Clearly somebody at the other end had heard of SOAP and recognised that 'everything is SOAP these days, we need to do SOAP!', but hadn't quite understood the point of it.

  • Little Bobby Tables (unregistered)

    Was posting an anecdote, but "Comment too long." Ah, blow it. Can't be bothered. I'll send it in as a regular submission.

  • sizer99 (google)

    A small WTF is still using case sensitive parameters if they can't be bothered to standardize them. startDateTime and StartDateTime or startdatetime should all work unless you're deranged enough to want startDateTime and StartDateTime actually be different things (enterprisey!) But these mopes can't even agree on whether to use StartDate and StartTime or just StartDateTime.

    It's obvious there was no design work here, someone just hacked together each message separately, aka it was accreted. Which is very enterprisey. And which means v7 ain't going to be any better. Nothing is going to fix this until someone takes every single message and refactors them all to be consistent with a standard for these AND future messages. And then good luck getting your outsourced third worlders to actually implement it.

  • (nodebb)

    I definitely agree with sizer99. There should be no case sensitivity unless it's actually needed. Case sensitivity is an evil that is only very rarely actually required.

  • ZZartin (unregistered)

    Gr..... web services that use HTTP error codes instead of returning a properly formatted response with an error in it are evil.

  • Brian (unregistered) in reply to ZZartin

    How about a response that includes both a meaningful HTTP error code and a useful error description in the body? Or are you one of those folks, like some of my former coworkers, who thinks it's a great idea to send an error message in a 200 response, which then requires special parsing of every response by the caller to determine whether the "successful" call really was a success?

  • xtal256 (unregistered)

    "There’s a simple rule about “enterprise” software: if the word “enterprise” is used in any way to describe the product, it’s a terrible product."

    To be honest, the same could be said of "open source".

  • Ulysses (unregistered)

    I don't see the big deal about iterations. The Starship Enterprise went through 1701, 1701 Refit, A, B, C, D, and E not including time travel shenanigans. Up through A it suffered from toxic masculinity. The D had adhesive issues and would regularly come apart under stress. The E finally got things right, so it absolutely had to get wrecked. Betazoids make awful drivers.

  • Fnord (unregistered) in reply to Ulysses

    Also not including NX-1.

  • Ulysses (unregistered) in reply to Fnord

    Ha, the NX-01 didn't even cross my mind, and that's for the best. :D

  • steve76 (unregistered)

    Sometimes I think it's easier to send the gateway to the PII than the PII to the gateway.

  • (nodebb)

    you’re on a fast track to bloated software, inner platforms, and just general awfulness.

    Today, we’re not talking about Oracle, though.

    Ha! Love it. And I must admit, the SOAP / REST webservices I have to deal with from Oracle are not as bad as the ones in the article. Still very annoying though, especially when they return errors for no real reason -- which they do on a daily basis.

  • Simon (unregistered)

    "REST that's not REST-ful" is just as likely to be a client-requested feature as a vendor one... they want "REST" to make their system integration easier, but what they actually mean is that they want simple XML or JSON over HTTP. They don't particularly care about the design principles, so POSTing messages to verb-based endpoints is fine... which is actually quite convenient, since it can largely be provided as a wrapper around pre-existing RPC....

  • P. Wolff (unregistered)

    Jacek is “eagerly” looking forward to v7 of this API, which is certain to contain more “improvements”.

    Reminds me of yesterday's comment

    Dave Aronson (google) 2020-01-20 Quote from one of my favorite web comics (Spacetrawler, by Chris Baldwin):

    Why ask "What could go wrong?" when one can simply ask "How entertaining will the fiasco be?"

    https://www.baldwinpage.com/spacetrawler/2020/01/08/010820-approxiscans/

  • (nodebb)

    In my experience "enterprise software" means "loose collection of scripts without installation program". It invariably also implies security issues that would impress a professional security issue creator. Finally it appears to attract management approval for any insane configuration if it is "required" by the "enterprise software".

  • (nodebb) in reply to Ulysses

    A few years back, I started using NX registry numbers for my projects, specifically because of that show...

  • (nodebb) in reply to sizer99

    startDateTime and StartDateTime or startdatetime should all work unless you're deranged enough to want startDateTime and StartDateTime actually be different things

    Anyone even noticing case sensitivity has already zoomed past sane when the implementer didn't publish a schema and/or the caller didn't use it. That was one of the best parts of SOAP. The world didn't get mad at SOAP until the javascript guys started trying to hand-build SOAP requests because their lame ass development tools (at the time) wouldn't generated proper code from a WSDL schema.

  • ZZartin (unregistered) in reply to Brian

    Yes that is exactly what you should do, HTTP errors are for errors in the actual protocol. Not errors that happen while the service is running. For example sending a request for a record that is not found is not an HTTP error.

  • (nodebb) in reply to ZZartin

    To be fair, it's a valid line of thinking to consider a subset of the url namespace to represent data elements. E.g. /customers/1 represents the url for the data blob that represents customer number 1. Given that thinking, a renumbered customer should return a 302 and a number that doesn't represent a customer should return 404. A customer that you don't have access to should return 403.

    I'm not 100% on-board that this makes things any better, but at least I understand the idea behind it.

  • ZZartin (unregistered) in reply to Jaime

    The issue is HTTP codes actually have real meaning to the HTTP protocol and subverting them for your web service error handling is just confusing. If I connect to the service and it runs successfully that is a successful service call from the HTTP perspective, even if from the application perspective it might not be. Just like how if I go to say amazon and search for an order number that doesn't exist I won't get a hard HTTP error I'll get an error message as part of the successful call to attempt to find order.

  • (nodebb)

    500 series errors are "hard errors", 300s redirect the browser, and 400s relate to content.

    For example, as a user, you might click a link and see a login prompt. However, that could have been implemented as the page returning a 401 and the browser prompting for credentials because the page told it to. This isn't a protocol level information exchange, it's an exchange regarding the rights of the current user - entirely an above-the-protocol thing. This isn't an abuse of HTTP codes, it's how they were intended to be used. People who want to control the login experience have abused the HTTP spec by returning a login page (with a 200 response code).

    BTW, I can't tell you how many times I've debugged a bad response and found that the server sent me a login page with a 200 code.

  • anonymous (unregistered)

    I could tell it was bad as soon as I saw both staffId and staffName in the "schedule a class" example. The ID should be used to look up the name in the staff database. I was surprised that this wasn't mentioned at all, as it is very likely to cause confusion regardless of whether the name field is used or ignored.

  • ZZartin (unregistered) in reply to Jaime

    It's not that the abuses can't go both ways, returning an improperly formatted response is a completely different issue. HTTP errors have very specific predefined meanings and subverting them for whatever personal use because someone is too lazy to properly handle errors on the processing side causes a lot of confusion and problems. For example some API's treat HTTP errors as exceptions that now have to be handled as special cases so even though there was no real error and it could have been handled in the return message it wasn't.

    As per your example, the issue was not the HTTP code, the issue was the response not being formatted properly, which would have been the case regardless of HTTP code.

  • (nodebb)

    The issue was certainly the code. HTTP 401 means Unauthorized, but prompt for credentials (as opposed to 403 - which means unauthorized, but credentials won't change anything). Login was required to access the resource, and they sent me a 200. That's the wrong code. Of course the underlying issue is that the HTTP spec is way behind real usage on the web. The 401 mechanism has no way to deal with things like "Login with Facebook". So, the web is now a massive teetering pile of hacks.

    Because of the wild popularity of this behavior in user-facing applications, it's very common to see it creep into API implementations.

Leave a comment on “An Enterprise API”

Log In or post as a guest

Replying to comment #:

« Return to Article