- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
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)
Admin
Well. That set of APIs definitely put the C in JSON.
Admin
My APIs which perform data updates always have a request boolean field called "performUpdate", which indicates whether the update should be performed.
Admin
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.)
Admin
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
Admin
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.
Admin
Was posting an anecdote, but "Comment too long." Ah, blow it. Can't be bothered. I'll send it in as a regular submission.
Admin
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.
Admin
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.
Admin
Gr..... web services that use HTTP error codes instead of returning a properly formatted response with an error in it are evil.
Admin
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?
Admin
"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".
Admin
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.
Admin
Also not including NX-1.
Admin
Ha, the NX-01 didn't even cross my mind, and that's for the best. :D
Admin
Sometimes I think it's easier to send the gateway to the PII than the PII to the gateway.
Admin
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.
Admin
"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....
Admin
Reminds me of yesterday's comment
Admin
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".
Admin
A few years back, I started using NX registry numbers for my projects, specifically because of that show...
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
I could tell it was bad as soon as I saw both
staffIdandstaffNamein 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.Admin
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.
Admin
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.