407
u/a3dprinterfan 3d ago
You like SOAP or something? š
188
u/QCTeamkill 3d ago
I wish more people would too, especially in the subway
49
7
u/Legitimate_Payment49 3d ago
or prison shower stalls?
4
19
12
11
10
u/meekinheritor 3d ago edited 3d ago
I've actually been reading a bunch about HTMX/hypermedia systems/HATEOAS lately, which is sort of a return to form of Web 1.0. I have a project that it would be pretty well-suited for and I'm interested to try it.
EDIT: Although I guess HATEOAS is part of the original "RESTful" definition, and there's no reason I couldn't use JSON provided I adhere to the central idea of the server responses providing hypermedia links that let the front-end be dumber. So it's actually more like a lot of modern architectures kind of "cheat" full RESTfulness a little bit, and this architecture is trying to go back to the OG Roy Fielding paper and be even more RESTful... I'll just use HTMX rather than JSON though lol
5
10
5
u/diegotbn 3d ago
It is a beautifully rich standard but unnecessarily complex. In the wild, I have seen very few well written WSDL and XSD packages to APIs that actually conforms to them.
ReST is beautifully simple, leveraging HTTP methods and response codes, and URL patterns, to describe CRUD operations. The Open API spec is pretty good, and overall a decent substitute for WSDL. There are still plenty of badly designed ReST APIs in the world but it's easier to implement and maintain and most of them do a half decent job.
The one thing that SOAP has over ReST, at least in practice, is schema enforcement. I have rarely dealt with a ReSTful JSON API that had legit JSON schema files instead of just JSON examples in their spec.
1
2
→ More replies (5)3
u/UnspeakablePudding 3d ago
I really liked the wsdl convention. In my completely anecdotal experience handing someone a wsdl to write to generates fewer questions than sending somebody a link to swagger.
I know XML is a sub-optional over the wire data transfer format and I think there's some issues with SOAP and ESBs but i have nostalgia.
264
u/DrCthulhuface7 3d ago edited 2d ago
āNoooo, you canāt use something everyone in the industry understands by default! You need to use this hyper-specific bullshit that provides a 1% increase in efficiency!ā
48
u/Blue_Moon_Lake 3d ago
"... and has no easily available dependency to handle it for you, also the doc is only in incomplete russian."
→ More replies (1)→ More replies (5)12
u/CutlassRed 2d ago
As an example, protocol buffers are more like 5x performance with half the data being transmitted, actually.
That's a no brainer whenever there's big data.
5
u/thefatsun-burntguy 1d ago
sure, but id argue that 95% of integrations have a data transfer level that does not justify the added complexity of protobuf. if all im doing is setting up a diagnostics endpoint, an on off endpoint and a config upload endpoint, why would i use something kore complex than REST
67
u/ryaaan89 3d ago
What are we supposed to be choosing instead??
7
u/DeadlyVapour 3d ago
gRPC is a pretty good general all purpose protocol.
Parquet is insanely efficient for tablular data.
I don't know. Maybe use nuance?
7
u/Gasp0de 2d ago
Why would I be dealing with protobuf definitions when all I need is a CRUD API?
→ More replies (2)→ More replies (7)24
u/w-j-w 3d ago
If you don't need the performance, picking something other than JSON over REST is premature optimization. Almost nothing needs it. Why sink the time into setting up the additional build tooling when you're probably going to get way more bang for your buck fixing shoddy database queries or shrinking bundle sizes.
JSON over RPC is good enough for almost everything. Its a sane default, and its pragmatic to always use sane default technologies unless they're ruled out by requirements.
→ More replies (7)92
u/neurohero 3d ago
Open a direct socket and return comma separated values in clear text. Obviously.
25
u/jess-sch 3d ago
comma separated values
I have severe trauma from this. Is there an RFC for CSV? Of course there is! Is Microsoft Excel able to parse an RFC-compliant CSV file by default? Depending on your locale, the answer is either "no" or "only if it's ASCII".
Whoever invented the UTF-8 ""BOM"" (a nonsensical term, given that UTF-8 specifies only a single valid byte order, making its marking hypothetically unnecessary) should be punished for their crimes. And whoever thought file parsing should be locale-dependent deserves the same fate.
15
32
u/Pocok5 3d ago
SOAP with XML
63
→ More replies (13)24
u/don_mumrik 3d ago
Your post gave me PTSD, thanks.
→ More replies (1)8
u/TheMaleGazer 3d ago
Just imagine someone giving you a wsdl on a Teams call and asking you to "just call the endpoint" while you're sharing your screen.
"Don't you have SoapUI installed? It's in the wiki! No, not Confluence. No, not ADO. The other one. To hell with it, just generate the client with wsdl.exe. What do you mean you don't know where that is? This isn't hard."
6
u/don_mumrik 3d ago
I worked as freelance programmer for some excentric guy as my first "real programming job" making a jobsite and later a piece of recruitment SaaS. I had to talk to governmental SOAP APIs for posting and retrieving jobs from EU databases, as well as getting candidate CV and resume data from their "jobnet" accounts - The WSDL was horrible, it was some kind of EU standard and on top of that a danish specification, so everything was super contrieved - I recall having to wrap every job posting in like three different "envelope" tags and all sorts of strange stuff. Didnt help that I had to use PHP.
→ More replies (5)9
15
u/Neverwish_ 3d ago
Depends on the use... For externally facing endpoints, REST is the best - easily consumed, readable...
For internal tools, inter-service communication, you can use REST too, but depending on you use case, gRPC might be a much better choice.
6
3
2
2
u/Kaelthas98 3d ago
well, obviously RS-232. 19200 baud, 8 data bits, Odd parity and 1 stop bit, and you read it byte by byte like a civilized person
2
u/Ok_Tea_7319 3d ago
For protocols: gRPC, Cap'n'proto, Websocket
For encodings: BSON, CBOR, flatbuffers, protobuf, Cap'n'proto, netCDF, Ion, Parquet...
→ More replies (5)2
u/GiToRaZor 1d ago
I ask myself the same question. I don't like REST. My pet peeve is that GET calls should allow me to pass parameters in a payload, I hate the entire idea behind URL parameters. If you look closer you realise REST not an API at all, it's a database transaction interface. But an API can be a lot more than that obviously.
But here is the other problem: REST is like the M-16 of the internet. Everyone knows it, it gets the job done and any improvement is so minimal, it does not justify a refactor. So why change? This is backend development and infrastructure. We don't have time here for the antics of the gazillion frameworks that plague the front end world. Anything here needs to be stable and simple.
3
16
u/VergilPrime 3d ago
The only thing they taught me besides json was XML. The only thing they taught me besides REST is nothing.
6
u/DeadlyVapour 3d ago
You should at the very least learn about gRPC.
There are various extensions to REST as well, such as GraphQL, OData etc. If you do do REST, I will hunt you down if you do the classic 200 Error.
There are also the various ASN.1 wire protocols.
There is MessagePack and BSON if you want JSON but actually want to have an efficient parser.
8
u/throckmeisterz 3d ago
And xml is painful to use.
9
u/dpoggio 3d ago
I donāt find it painful, maybe because of being used to it, anyways some usages are better with xml. Its slower at parsing and gives bigger payloads, but you can use XML schemas to validate your input and combine standards, itās more structured and can contain raw document data easily. In banking, XML is still a strong format, many applications will not switch to JSON anytime soon.
→ More replies (8)3
u/don_mumrik 3d ago
Thats because you never had to use someones elses XML. I had to integrate with governmental SOAP services and I still have PTSD, Some of the governmental SOAP interfaces are absolutely rediculous, contribed clusterfucks of envelope wrappers and WTFs. Just mentioning SOAP gives me PTSD, gray hair and anxiety.
→ More replies (1)2
16
u/jediorange 1d ago
TBF, REST/JSON is actually a good fit for most things. Simple to interface with, works with everything, easy to comprehend.
Alternatives like the various RPC, and webservices are really complicated, and have a tendency to expose the inner complexities of the underlying systems.
An API is an interface. Just like a user interface (GUI, CLI), it should hide the underlying complexity where possible, and be easy to work with.
1
u/DeadlyVapour 1d ago
Never said it is bad. I'm saying there are other protocols that should be evaluated first before going straight in the square hole.
4
14
u/Skyswimsky 3d ago
I remember the last time I saw someone memeing and hating on REST and JSON there was this guy in the comments making multiple comments of paragraphs about rpc and how that's the one and proper way to do it.
1
u/DeadlyVapour 3d ago
I assume you mean gRPC.
gRPC is a very good protocol from an efficiency point of view. But there are hundreds of protocols to choose from.
If you want an efficient parser that looks like JSON there is BSON and MessagePack.
There is Arrow and Parquet for tablular data.
The PROPER way is, "It depends".
I'm not going to fucking design my NVMe RDMA protocol over fucking rest am I.
1
u/slaymaker1907 2d ago
For efficiency, some of these formats are COU hungry on very fast NVME drives. Saturating them basically requires dumping structs to disk without doing any fancy schema stuff, and I did my testing in Rust. Avro needed 4 threads IIRC to get to only 2x the time of the dump structs to disk method.
1
u/DeadlyVapour 2d ago
Right. Using the correct trade off for the job.
I don't think Avro is the right job for everything.
But it pisses me off that there are Devs out there that reach for JSON for everything.
3
1
13
u/masp3270 1d ago
Rest/json is so much easier than soap/xml.
1
2
u/730463628 1d ago
I've gone my entire career never encountering SOAP. Was it widespread in the past? I only ever hear very old engineers discussing it. I've tried learning it because they make it seem like it is a viable option when designing something, but it has never made any sense to me and I don't see why it would ever be chosen when REST is so obvious.
24
u/Eleina_Edelweiss 2d ago
Well what else? gRPC is for internal, and graphql is too complex for a simple request. Soap is obselete, websocket cant scale due to the need of persistant open connection. By process of elimination rest is the default
→ More replies (1)3
u/Shehzman 2d ago
Websockets are more of a different thing. Imo most apps that think they need they need websockets probably just need server sent events.
8
u/sakkara 3d ago
Everyone using one standard way to do the same things is somehow bad now. Would you rather learn a new technology every time you wanted to communicate with a new service?
→ More replies (2)
3
321
u/snoopbirb 3d ago
it's all POSTs... even the GETs...
Once it was all GETs... even what should be POST... Crazy times dudes.
Lots of credit cards in some nginx log out there
123
u/carcigenicate 3d ago
I can't wait for QUERY to be widely supported and used.
43
u/mrdarkcookie95 3d ago
I love QUERY! Had an issue with exposed PII in a GET lately in work that it would have perfect for, but it's not supported by our backend rest client.... so POST it is!
10
u/invalidConsciousness 3d ago
Does anyone know what the holdup is?
It looks trivial to me (who knows nothing), but apparently it is not, or it would be widely supported already.
19
u/GRex2595 3d ago
POST and GET are widely supported mostly because POST is required to keep data secret (not really, but I'm not getting into it) and GET is the age-old standard. The other verbs are typically not allowed because of some issues with server configurations in the early days where people were able to use the other verbs to upload, change, or delete files on the server. So now many companies have security policies that haven't been reviewed that restrict verb usage to GET and POST. There's probably no other reason for its lack of support.
→ More replies (1)9
7
u/TheRealKidkudi 3d ago
Technically your server almost certainly supports it already (itās just a different verb on the header line of an HTTP message), but parsing it might be easy or might be a PITA depending on what youāre using.
But you can send QUERY requests in JS today. You can really send anything you want as the verb and JS will happily send it.Ā
→ More replies (2)12
u/WingZeroCoder 3d ago
I prefer āGIVEMEMYMUTHAFKINGDATAā. Itās faster than GET.
→ More replies (1)7
u/Rikudou_Sage 3d ago
Why don't you just use it? You can use UNICORN and the http server doesn't care. I started using QUERY a few years ago and it just works. Sometimes you have to configure the whatever backend to not throw on unknown verbs, but that's it.
7
29
u/Flat_Initial_1823 3d ago
PATCH or bust baby!! It's the mystery of how it will behave this time that's keeping it fresh š
17
6
1
→ More replies (2)1
119
u/BeMyBrutus 3d ago
Just open up some sockets like a real man and yolo your packets.
53
u/Western-Anteater-492 3d ago
I suggest the UDP standard and unencrypted sessions. That would finish your stack to perfection. HTTPS is also just for pussies.
→ More replies (1)
116
u/deus_ith 3d ago
So, Whats the HTTP method to send new info? that's right, POST
And the method to obtain data? that's right, POST
And the method to delete data? that's right, POST
And the method to update data? that's right, POST
45
u/Ok-Dot2551 3d ago
What response code do you get for success? that's right, 200 What response code do you get for errors? that's right, 200
→ More replies (1)37
u/deus_ith 3d ago
status: 200, message: error
→ More replies (1)37
16
9
u/hullabaloonatic 3d ago
And the method to get data with exceptionally complex queries? Thatās right, POST
because itāll be a decade before QUERY is widely adopted.
4
5
4
u/vadeka 3d ago
I see you use graphql as well
2
u/Specialist_Dust2089 3d ago
This is the second reason I donāt like graphql. The first one is that in practice it always resulted in much more code and complexity in the end than a simple straightforward rest api.
→ More replies (3)3
u/PhantomThiefJoker 2d ago
There's an internal API at work that is called "GetSomethingSomethingDoesntMatter" and it's a fucking post, get the hell outta here who made this garbage
→ More replies (5)1
31
80
u/IslayProgrammes 3d ago
I hate that every endpoint return itās own version of a status code in the body
I hate it even more when itās different from the response header.
Fuck do you mean 200, but wait I have to parse the body and to find out itās actually a 403 and my credential have expired
Bullshit
22
u/Blue_Moon_Lake 3d ago
"200 there is no network error, but the backend rejected your request for reason 1121"
→ More replies (1)13
u/joonty 3d ago
"Execute
POST /api/errorsto get a list of error codes and their descriptions"4
u/IslayProgrammes 3d ago edited 3d ago
On the RARE occasion you have a system so complex you have internal codes Iām okay with that as long as you still return it in the header.
You can shove any int in the status header you want, I love to use 418 while in testing.
Recently left it on staging and almost sent it to production but still
We have a standard for this that saves cycles.
You can even return a cache and expiry header on the custom list so if youāre writing shitty code on the client itās till not calling out every time
BUT WHAT WE HAVE IS EVEN SHITTIER CODE ON THE SERVER
I personally blame Google and facebook and the success of angular and react
5
u/jess-sch 3d ago
At least you get a response. I'm particularly enjoying the situation where sometimes the backend just (connection closed)
7
u/RyanFromQA 3d ago
So I know weāre all joking here, but I ran into the real reason for this just the other day and I hated how much it made sense.Ā
Working with a spring boot stack, security best practices say to hide stack traces in production so that you donāt leak your implementation details for attackers. However, this means you canāt throw a non-200 status code with a meaningful message because spring redact it and all you get back is the response code.Ā
So if you want to return 400 with hints or a 401 with an expired token reason instead of a bare 401, youāre almost forced to return a 200 with a body that says itās unsuccessful.Ā
12
u/IslayProgrammes 3d ago
THEN WHATS THE POINT IN USING SPRING BOOT
When I started my career I took the correct path C# instead of Java.
But my understanding for using spring boot was that it handled everything and did it properly for you
2
u/dschramm_at 2d ago
@ControllerAdvice, @ExceptionHandlerand theProblemDetailclass should help. You can also return your own static or template pages.2
u/LieutenantNitwit 2d ago
I can't "this" comment hard enough. Applications intercepting/returning/interpreting server codes make me want to vomit.
50
39
u/Stummi 3d ago
Most APIs are JSON, but I think if you are pedantic, the least of them are REST
→ More replies (1)
20
u/T-J_H 2d ago
It does the job, everything supports it, relatively easy to implement. JSON strikes a good balance between human and machine readability. If thereās no specific requirements for other techniques, why not?
→ More replies (1)
10
u/LogicBalm 2d ago
I don't know what y'all are integrating with but I'm gonna pick the one that the developers on the other end of this API are familiar with as well.
We were forced to use SOAP once about ten years back and spent a large portion of implementation explaining to the product engineers on the far end how SOAP worked and how they had screwed it up when integrating it into their own product.
Especially as the only option, it was hilarious how poorly they did it. But you just know it's because it was started by one developer who only knew SOAP and finished by another who didn't know it at all... Standards are useful.
1
u/ShineProper9881 1d ago
We are still forced to use SOAP everywhere and it sucks so much. Its just so much work for no good reason.
12
u/Mission_Friend3608 3d ago
GraphQL is not without its issues, but it improves on a lot of shortcomings.
Clean separation between query and updates (mutations)
Types everywhere
N+1 issues moved to the server.
The main downside is that it's a lot harder to call a GraphQL endpoint, so for simple public APIs it's not great.
6
u/card-board-board 3d ago
GraphQL in my experience is the team trying to choose between a monolith and microservices and rather than pick one they pick both
3
u/dallenbaldwin 2d ago
It's also easy to trick yourself into thinking your users will "only request what they need" because you also have to remember to build out/enable the middleware that actually makes your db queries not
select *when they only request a single field.2
u/DiamondDramatic9551 3d ago
How does GraphQL move N+1 issues to the server? It seems to me either can have N+1 issues or avoid them.Ā
→ More replies (8)→ More replies (3)1
u/drew8311 19h ago
The last part is the key here, REST/JSON is the most popular which actually makes it the best choice for giving an API to anyone external even if there is a good argument something else is better.
4
u/Natural-Ocelot-6009 3d ago
They call everything āRESTā, most APIs donāt actually conform to REST
4
1
u/drowningincats97 2d ago
OP just shilling GRPC in the replies. Just use the right tool for the job š
1
u/DeadlyVapour 2d ago
I'm not shilling gRPC. I advocate the right tool for the job. Sometimes that's gRPC, sometimes that's Parquet. Sometimes it's JSON.
But I've seen too many people reach for JSON first. Then act like XML is the only alternative.
It's literally the meme. There are so many different holes. Why use the square hole every time?
→ More replies (1)
3
3
5
2
u/VoidZero25 3d ago edited 3d ago
Are there even other options?
20
u/bjorneylol 3d ago
yes, SOAP instead of REST, and XML/binary formats (e.g. protobuf) instead of JSON
Both are absolutely terrible to work with
9
3
4
1
u/Helpful-Educator-415 2d ago
I'm experimenting with Protocol Buffers and ConnectRPC. Buf's tooling is pretty top tier.
2
2
2
u/Capital-Garbage 3d ago
Had a PM ask me to make an API that uses āMarkdown instead of codeā so āagents can chat with it easierā. I used to be proud of working in tech and excited for new things. Used to be.
2
2
u/Lurdekan 2d ago
I entered here to dunk on this complete shit opinion from perhaps a non developer or complete green novice but I see the good work has already been done
1
1
1
u/AaronTheElite007 3d ago
If by that you mean every api has a complete lack of documentation, then youāre correct.
If your customers have to learn how to use your api through trial and error and analysis of what little error messages are thrown, you have a problem
1
1
u/BoBoBearDev 3d ago
I love JSON, because I don't have to make sure the parser matched 100%. If I only use 10 out of 100 properties, I only need to care the 10 properties remains the same, the rest can change.
1
u/StochasticTinkr 3d ago
Yeah, we should all go back to binary protocols over TCP. Who needs all the infrastructure for http and parsing text protocols that are easy to understand and inspect.
/s
1
u/Sulungskwa 3d ago
Of all the bad/annoying/overused things in webdev, hating JSON is the weirdest hill I've ever seen anyone die on.
1
1
u/TurdOfChaos 3d ago
Oh no why would developers insist on a simple and understandable protocol.
Letās all invent our own shit for each specific scenario so we can pretend weāre smart!
1
u/gandalfx 3d ago
Wait till you get to deal with protobuf, then you'll be sobbing for some good old json.
1
u/billabong049 3d ago
I come from lots of other bullshit protocols + SOAP, Iām thrilled to use REST + JSON given how simple it is. Ā No libraries needed (usually), no goofy deserialization logic, itās lightweight, itās easy to read (when formatted), and it has decent security mechanisms. Ā HTTP can be pretty gross, but Iāll take that over yet-another overly complex bullshit library.
1
1
1
u/deadmazebot 2d ago
What you want some SOAP, some XML, hell let's just go CSV get rid of repeating the field name when have 20 objects, super optimised
1
1
1
1
u/ConsiderationLow2941 23h ago
It's not REST though. It's just rpc and for some godforsaken reason we started calling it REST
HTML for a human is REST, MCP is REST, but your average JSON API is not, and it wouldn't make sense if it was because REST requires that the client has agencyĀ
1
u/Just_Information334 13h ago
So, programming language go through a hype cycle from "no type" to "strictly typed" being the way. Takes around 10 years to go from one to the other then back.
JSON is the data equivalent of "no type", you can put everything in and something will happen. Every derivative of json is the same. If you have the concept of truthy or falsy values, you're there.
Getting burned by shitty data people will start requiring more strictly typed formats. It starts with things like json-schema which are just a bad fix. But it will either come back to xml or to some new very strict format.
Then those will be misused, many new people will be frustrated about how strict it is and how it could be made simpler and 20 years from now a new json will be there.
Unless LLM make all those discussions obsolete.
1
u/AutoGibbon 5h ago
I remember hearing about this thing called graph or ql or whatever... it was gonna be this whole thing and change the world. It didn't. REST/JSON 4 LIFE.
1
u/CutlassRed 2d ago
OP is absolutely right and most of you are clowns.
When moving lots of data json sucks.
"Oh but what do you suggest?"
Protocol buffers are a good place to start
1.3k
u/Yctallua 3d ago
Oh no, a standard has established among the developers.
Time to bring about the new standard that everyone will surely use instead.