What is with medium.com? Why is it so many links to this site are full of hateful hipsteresque opinions looking to sound smarter and more insightful than they actually are?
What is with medium.com? Why is it so many links to this site are full of hateful hipsteresque opinions looking to sound smarter and more insightful than they actually are?
And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?
https://userstyles.org/styles/browse?search_terms=medium.com
then, it's only alt-B -> 1 away, in Firefox
Personally I will keep using REST. If I ever find something is too CPU or network hungry with http/JSON I will take a look at a binary protocol.
For me REST has opened up the world of web applications to simple integrations. It is what makes simple, single use case web apps useful.
Agreed, its a content platform with a where the content fights for attention with the medium.com branding. How many people do you really "never miss a story from"? I generally avoid medium.com for this reason alone.
I'm further puzzled when I see companies using medium for their company blog as well. All I can figure is it must be recommended in some user guide to "growth hacking."
Being in a known content container is great if you don't have your own "brand" and as long as people associate the container with good content. If they don't, or if your content is way above average, it pulls you down (which provides motivation for below-average writers to write on them, hiding in the crowd, and motivation for good writers to leave)
WordPress, on the other hand, is open source software you can host it yourself and thus you can't just slap some tags on it and get featured on top of a newsletter. This is also why some authors prefer medium, easy to setup and easier to get an audience, but then you have to resort to these marketing techniques to drive your views up.
Disclaimer: I have written some medium posts with catchy/controversial titles to test said techniques, call me part of the problem.
As a note aside, the xmlrpc endpoints of the aforementioned system worked fine and saved us time.
Xmlrpc is soap without the bullshit.
I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps
I remember well the meeting when things started to go off track...
XMLRPC or JSONRPC seem to be the happy middle ground.
The posted article hit home with me as I had to re-implement working SOAP services in REST because you know, management buzzwords and new shiny.
I quickly found, as the article articulates, as soon as you enter the land of verbs and workflows REST starts to stumble and becomes very network chatty. And when that network chattiness is backed by other network chattiness the grumblings of why the hell you can't just return a deep object graph of data from an endpoint ensue.
My question would be, outside of convenience to SPA developers, what do you see as the specific advantages to REST over XML/JSON RPC or SOAP?
If you control client and server and the server's functionality will for the foreseeable future is limited in scope, xmlrpc is the boss.
We had a django/rest based internal microservice. Was a pain to build and maintain. Switched to xmlprc (it's in Python stdlib), removed tons intermediary code, and wrote only a few bits of new code.
This talk by Jonas Neubert opened my eyes to how xmlrpc can be the glue for Python (which is already glue).
The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works.
After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice.
In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP.
PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good.
Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.
Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap
There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work.
While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
I think that's the link missing for most developers. SOAP was intended to allow machine-generated SDKs to remove all of the sharp edges of dealing with it, and in that regard it was largely successful. What brought it down was the advent of non-"enterprise" web development—development happening outside of a .Net or Java IDE that generated code for you. If you ever had to handroll a wrapper for a SOAP endpoint though, god help you. I honestly believe SOAP was the thing that made XML seem uncool by comparison to JSON and REST. JSON still doesn't solve data representation problems as well as XML, we've just learned to accept "good enough" in its stead.
I've tried suds and zeep. They both didn't really work in my specific cases. My strategy from now on is to write a bit of code in Visual C#, then analyze the xml traffic, and then generate that same XML using Python/PHP. The SOAP protocol is actually pretty simple once you know how it works.
SOAP has a lot of problems, but it's pretty amazing that you don't need a client side library to use it in Visual C#.
REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer.
The main cause you don't need REST limitations to achieve same goals.
OP has strong opinion about why we need to reimplement rpc over http every time for every application and write clients for every popular platform to be able to consume it.
Every time I use REST from any google cloud api, my hair is moving and you definitely will have nightmares if you look into their python client code.
The remainder.
I've been curious to see one (for years). Everyone talks about how this REST service is being done wrong, but few will link to services being done "right".
The truth is that these sites are, in fact, RESTful and that REST is just mediocre at what it professes to do. The requirement to treat all operations as resources + HTTP verbs is the primary leaky abstraction that everyone seems to want to gloss over.
They can have the same root cause though: someone's identity feeling threatened.
OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for.
Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much.
REST is more of a philosophy, than a standard. Hence everyone does it differently, and you have no chance to use the same library to talk REST with multiple different services (unless you make that library an overcomplicated beast).
XMLRPC? It's a universal standard, that is just a few pages long and everyone can grasp it in their lunch break. Nobody would complain that your API is not "XMLRPC enough". It works (almost) the same way everywhere. You can get the XMLRPC library that's been built in since Python 2.2 and be reasonably sure that you are going to be able to talk to a random modern XMLRPC API. You'd have other such libraries for every major language. Ditto for JSONRPC, if XML sounds too scary (though it doesn't really matter much - it's a mostly transparent implementation detail).
I'd wish people would stop bringing up SOAP as an excuse for REST. Yes, it was worse, but that does not mean that REST is particularly good.
The REST way allowed one to get started with something small and simple that people could agree to just by talking it over together. With SOAP you had to make all those decisions up front and put it in the specification. I believe SOAP is so complex that it's an analog to CORBA/IDL.
REST is (at least initially) simpler and less specific than SOAP. That's its strength.
SOAP was intended to facilitate the same programming model but more loosely coupled. So that's not at all far off. And for what it intended to be—a specification for machine-generated bindings and SDKs—it was quite successful. It just didn't make the usability leap over to web development that happens outside an IDE.
It may have to do with the platform being used by individuals trying to create a brand of themselves, resulting in a high percentage of sensationalist and controversial posts. Along with the necessity to write on a regular basis.
left: it gets stuff done because it's smarter
right: it's bad for you, it's actually getting less done
middle: didn't read all that stuff, busy getting stuff done.
I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-culting are personality traits of many programmers, and I've come to the conclusion that its best to accept this, and get on with the job of actually delivering value.
Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good.
But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
Having shitty paradigm is certainly better than having none at all. But at some point we have to evolve.
Read. The. Damn. Stuff.
Could have given the exact same non-argument for SOAP -- which in its time dominated corporate services.
Whether it's "easy to implement and works for lots of use cases", it's a moot point if there would be something even easier to implement and worked even better for real use cases.
Why stop at "easy" when you can have easier AND more coherent?
Besides, REST is anything like easy. Case in point, almost nobody ever correctly implemented the original REST spec -- that's why everybody calls their implementations "REST-ful", they are some loosely inspired deviations that cargo cult a lot of useless junk.
Supposedly the "real illuminated REST" (like real communism) doesn't even concern HTTP, it's a philosophy beyond web services. And yet's it's all the web related garbage part of the introductory examples that everybody follows (or tries to).
It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles.
Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a CORBA equivalent and then almost succeeded with SOAP/WS-*. People got strident to fight the dollars that were lined up. It’s easy to forget there was no powerful web/internet community with social media and blogging platforms in those days, it was all mailing lists and a couple of conferences vs. Marketing budgets, sales teams, and agenda-wielding engineers on standards bodies from Microsoft, IBM, BEA, Sun, HP, etc.
All RESTful means is that something is attempting to conform to the style. There never was a spec.
It's application for what are essentially RPC needs is which I consider cargo cult.
The HTTP REST came from people mapping HTTP verbs to RESTful actions: http://cafe.elharo.com/web/why-rest-failed/ (2006) to https://martinfowler.com/articles/richardsonMaturityModel.ht... (2010)
The people you describe used to have blogs with crappy Wordpress themes that barely got noticed by Google, now they are on a big site so get discovered I guess?
IMHO REST is not easy to implement, it's easy to say "oh... okay I think I've got it... let me try" but it's very hard to implement RESTful APIs and the author mention a few valid pain points.
Simple use cases like: a user forgot their password, what the proper way of handling this case? A PATCH for a User based on ID? If the ID is a integer ID then you have to query user by email or username before you are able to request a new password, if the PATCH handles this case what other cases does it handle? Can a user request a new password and change their age at the same time, is this a valid case? How you structure your controller to route to these special cases, do you create a custom endpoint thus making your API less restful?
One thing I like about GraphQL is this idea of mutations, in many cases they are analogous to RPC calls, `userForgotPassword(usernameOrEmail) -> forgotPasswordResult`.
If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical.
Right now is full of "Content Hackers" trying to make reputation.
For example, xmlrpc has been recommended in comments as alternatives to consider. Maybe what's wrong with Medium is that the informative replies are on HN... (to be fair, grpc is mentioned on Medium.)
Twist on “easier to destroy than create.”
You think this guy is a hateful hipster, but most of what he says probably resonates with most software vets. To me, it's mostly against the REST zealots who demand REST is done in a very particular manner. I've seen companies with a very stable, robust RPC framework that had a small faction of REST zealots who were extremely against it because it didn't do things according to REST. It didn't matter to them how stable it was or how well it worked.
Also, REST is relatively not popular - what percentage of the world's APIs use REST do you think?
TBH, you're the one coming off like the hateful hipster to me.
Furthermore, and it's been this way for as long as I can remember, too many want a tool to be the perfect fit for every problem.
That is, they pick up a screwdriver and then are shocked that it's not good for driving nails.
There is no OSFA technology.
There are HA microservice and REST model libraries/clients that do it much easier and without XML :D
You have to give it up to Colfer protobufs on zeromq and kafka :D
edit: stray click
GRPC is fun too. I miss my fiber interconnected compute though.
Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.
Many languages support auto generation of consumer and producer code based off of WSDLs.
And AFAIK, most languages that don't have the auto gen tools do have XPATH libraries for easily manipulating templated SOAP requests.
It takes just a few clicks to generate complete set of requests from WSDL (set, as in "one request per each operation"). I think it's much better user experience than hand-crafting json to use with curl.
If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update).
But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
SOAP's big problem, IMO, was the crazy insistence on URI formatted namespaces, which took a simple XML message and turned it into something bloated and confusing.
I'm not part of the new world so I guess I don't feel at home there.