Watch the Startup Lessons Learned Conference - <AUTHOR> http://www.justin.tv/StartupLessonsLearned

<comment><USER2> Here is a list of speakers:

<http://startuplessonslearnedsf.eventbrite.com/>

The first keynote is at 9:30AM Pacific.

</comment><comment><USER3> Does anyone know if there will be hosted videos at some point? I'm not able to watch the live streams :(.

<comment><USER4> At the moment you can view the videos of the day here: <http://justin.tv/startuplessonslearned/all#r=pB2rhdQ~></comment></comment>


Ask HN: Technology and framework for file storage web service - <AUTHOR> I would like to develop an application (not necessary a web page) that will be able to handle my requirements which are:
* file uploads (with meta-data) which I would like to store in one specified directory on server (meta-data would be in SQL database),
* text data (with structure or without),
* handle JSON queries so I will be able to get information/data from server.
Is there any kind of framework that will allow me to quickly create such application and help me storing and retrieving data with JSON queries?
Maybe (but not necessarily) there is a python framework for that? <comment><AUTHOR> I got the tip to use Flask ([http://flask.pocoo.org/](http://flask.pocoo.org/)) and it turned out to fulfill my requirements. Thx for the answers.

</comment><comment><USER2> use Ruby on Rails with carrierwave gem to upload files to AWS s3

write your custom api in rails to serve those files</comment>


Ask HN: What would you do with a year off? - <AUTHOR>

I am taking a gap year and have no obligations from June of this year (when I graduate high school) until at least August 2016. At this point, I have no idea how I'm going to fill all of this time. I'd love to hear your suggestions for how best to take advantage of this opportunity.
A couple of notes on my situation:
- I'll be a minor (< 18 y/o) for this whole time period
- I have saved up a good amount of money from working this past year, so I'm okay on that front as long as I don't go crazy
- I've been accepted into a top-10 Computer Science program for admission this fall that doesn't let students defer for a whole year. I feel like I have a good shot at a top-5 or top-3 school if I apply again this fall (for admission next year). I don't necessarily want to go to college yet, but I also don't take being accepted there for granted.
- I'm located in the SF Bay Area
Cheers :) <comment><USER2> Whats the point of taking a gap year? I wouldn't take this unless you are extremely dedicated to some task, like a budding business, a dream to do something, something you are entirely into, not just an vague idea about taking a year off, especially considering you already have a top school accepting you. Waiting longer will probably only hurt your chances to get into a better school, not improve them. Beyond that, many people have taken "breaks" from school and then life catches up, so they never return. I would seriously consider just sticking it out and attending college. You'll have a lot of free time in college, at least in the beginning, to explore your own interests.

<comment><USER3> I disagree. After high school I didn't know what I wanted to do and during the time I took off I discovered computers.

If you have any doubt about what you want to do in life take some time to think about it.

</comment></comment><comment><USER4> \- Go on a long term international trip to find out how things work in the rest of the world. Particularly Europe, Asia.

\- Blog several times a week about your new experiences.

\- Volunteer for stuff to meet people, concerts, events, conferences, sporting events.

\- Start a side project so that you will be ready to kick butt when you do start CS.

<comment><AUTHOR> \- Any recommendations for specific places? Spain (I speak Spanish) and Japan are my top two destinations as of now

\- Definitely.

\- Sweet - would you recommend any organizations that organize this kind of stuff, or am I better off just googling around for things in my area?

\- No question.

Thanks!

<comment><USER4> I'd google for organizations you can help, but some ideas \- Habitat for Humanity (Global Venture could be good for travel too), a local ReStore, or a local house. \- A Meetup Near You \- A Startup Weekend Near You \- Ask a coworking space if you can be a coffee and copies intern \- Craigslist Gigs \- Your local church might know something.

</comment></comment></comment><comment><USER5> Undergrad time in college is the perfect chance to explore and figure out what you want to do. I would recommend starting school, and taking a lighter course load including some things you might not take otherwise. I was a mechanical engineering major in college, but I wish I had taken more CS classes. If you have the means then plan to spend 4.5-5 years finishing school, or save your money so that you have more options after you finish college.

I took about half a year off before grad school, and I loved it. For me that was much more valuable than if I had done something similar before undergrad. If you are interested, I spent my time off on a road trip across the US. My wife and I camped the entire time except for a few days with friends and 3 nights in hotels when we need some recovery time. It included a lot of hiking including up to 15 days straight on the trail.

</comment><comment><USER6> I've been wishing as a 29 y/o that I could find a way to take a year off from work without it financially ruining me, and spend that time both traveling and coding. I still have a lot to learn, but I've always had this burning desire to code deep down. It has manifested in building websites, but I want to dig deeper. I'm doing so to an extent, but with other obligations in life (mostly work), it ends up going on the back-burner more than I would like. I feel like I need a year of rearranging my life. A complete overhaul. Even if it's not all coding, but working for a non-profit or volunteering, doing other things that affect the world in positive ways, and/or traveling while doing these.

I have traveled before and it was great to see the world from a different perspective. I feel I need that again. Maybe call it an expensive empathy- building exercise.

</comment><comment><USER7> The most important thing to do with your gap year is to really thing about what you actually want to do with the next few years of your life. Chances are you've never really thought about it.

Certainly I just assumed that since I did really well in high school, enjoyed physics and got into a good school then studying Physics at University must be the right thing do. Since this matched up with all social expectations and since everybody around me told me that this was a really good idea, I never really questioned it. To cut a long story short, it probably wasn't the right thing to do then, and I ended up miserable and crashing out.

So whatever you do end up doing with your time, take the luxury to throw out any pre-conceived notions of what you should do and really reflect over what you want to do.

</comment><comment><USER8> I'm working full time now and wish I had time to pursue artwork. I am now making photographs and printing them. But to really complete my concepts I need time and resources.

If I had your year, I would find some art form and try to perfect it. Then go back to CS in the fall.

Another option: go to Asia. And scuba dive. You can live in India for awhile for little no money. I spent 4 months traveling, diving and shooting photos and absolutely loved it. I don't think I learned a whole lot. But it was heaven.

Maybe do that and have some goal in mind. And if you do travel, you're going to take photos (how can you not?). So get good at making photographs before you go if you do (take a street photography class).

<comment><AUTHOR> Awesome :) I'm very interested in photography, and I'm determined to document the year, so that's something I'll definitely be getting into.

As a minor, traveling is a bit more trouble (not impossible), but getting away for a few months would be amazing. Thanks dude(tte)!

</comment></comment><comment><USER9> Personally, I'd lock myself away and write a bunch of Apps.

If I was you, I'd do some cheap traveling in South America or Southeast Asia.

</comment><comment><USER10> Man, If I had the money, I'd take the chance to see the world. Run around Asia and Europe and (the safe parts of) Africa. Meet some people. Find some good problems to solve. Build networks for future ideas. Maybe even fall in love ;)

I work full time now at a fantastic job but I often wish to venture to places that technology haven't penetrated very deep and learn more about social structures and how oppressive they can be in the eastern world. A young person with passion can do a world of good things if they can find the right problem to solve, the right solution, and the right partners.

Best of luck!

<comment><AUTHOR> Thanks! Being a minor restricts a lot of my options as far as being in less- developed countries for too long (liabilities, etc.), but it's something I'm interested in.

Any suggestions for specific places to go?

</comment></comment><comment><USER11> I hope you had some kind of plan before taking a year off. But maybe you just wanted a break from all the non-stop studying (since you were a child).

There are so many ways... As extreme as: lock yourself in your basement and code for a year, all the way to travel the world. How many countries have you visited so far? If less than 3? Definitely try to double that number.

You want to do crazy experiments (like Justin.tv)? Remember these recent posts about a github project that will accept any pull request? Let people suggest stuff, and do them (and report) [within reason].

<comment><USER12> Totally agree with alain94040. Come up with some crazy experiments to run and weave travel into it. Off the top of my head:

* Visit an elderly center, tell them you're traveling, and let them request certain attractions in the city you're in. You GoPro the whole thing and upload it for them when you're done.

* Come up with an interesting question and ask people as you travel e.g. "what do you think of americans?" , "what do you think of america?". Share the responses on a blog.

* Go to Cuba and capture the density of wi-fi signals you get. Document it in such a way that someone besides you could rerun it in the future.

Count me as jealous. Have fun and good luck!

</comment></comment><comment><USER13> I have taken a year off. It was great the first six months, then life caught up and it was just a race to get back to cashflow positive. The last six months undid everything good the first six did.

<comment><AUTHOR> Huh, that's interesting. I have the option of taking just 6 months off and then going to college in the Spring semester - is that what you would suggest doing?

If you don't mind me asking, do you think you could go into more detail about what made the first six months great and the next six not so much?

<comment><USER13> If you need to take time, do. If you don't need to, don't. That's the most I can say on that matter. I didn't go to school in the traditional sense, so whatever makes sense for you makes sense.

What made the year off sort of a zero sum was that I had roughly enough cash to last roughly a year, but at about the halfway point I started looking for areas that I wanted to relocate to and worked on securing employment there. The stress of re-entering the workforce undid some of the decompression from leaving the corporate world in the first place.

It was a great period for figuring out just what I wanted to do and what really mattered in life. If I had to do it again, I'd have more FU money, or at least have a more solid income stream that wasn't wholly dependent on me being at an office for ~8 hours a day.

Lessons were learned, some easy, some hard. Plans are in action so that history won't repeat itself so closely next time I decide I need some time off.

</comment></comment></comment><comment><USER14> I think the biggest mistake people make is not "building their brand." Create a presence online, create one in meatspace and get known as someone worth knowing.

For reference, I took some time off and wrote a book on a technical subject, created two big meetups and got hooked in with the local startup community. Now I go to local events and people are starting to actively seek me out.

<comment><AUTHOR> Sweet - I'd be lucky to accomplish half of that.

Re: networking - do you think age is a factor? In your experience, have these meetups been inviting, or did it take a lot of effort on your part to start making connections?

</comment></comment><comment><USER15> Just a different point of view, but when I finished high school I couldn't wait to get into university and start studying maths. I would have hated to have a gap year that would have delayed the amount of time before I start.

So not sure why you would take a gap year without knowing what to do. Makes it seem like you don't want to study computer science?

So maybe you can question why you are wanting to study? Is it your favourite subject? Do you code for fun? Is there another subject you'd rather be studying, but maybe isn't as 'acceptable' with the various pressures to conform?

Hope this doesn't sound to harsh, but it is worth thinking about what you really want. Maybe THAT is why you need the year out.

If so then I would suggest some kind of travel. Get away from the peer / teacher / parental pressures and enjoy yourself. You might get a feeling about what you really want to do.

If you go crazy from not being able to fire up your IDE and crank out code, you may find that CS is right for you after all :-)

</comment><comment><USER16> I would probably sit down an write an entire video game in the style of some old game that I liked

<comment><USER17> What kind of style?

</comment></comment><comment><USER18> Travel, learn a human language.

<comment><AUTHOR> I speak English + Spanish, and want to learn Chinese but it's so different from the others. Thanks for your suggestions!

<comment><USER18> I've successfully learned Chinese fluently. Spending a year hanging out in a nicer part of the mainland while working through books and paying a teacher for 1-on-1 lessons a few days a week (~100CNY=$16/hr) should get you conversational. I strongly recommend considering Yunnan: good standard Mandarin, excellent weather, friendly people, good food, many points of interest. Americans can now get 10 year visas easily, though you have to exit the country every 90 days. This means you don't have to tie yourself to a formal school and its (slow, tedious) pace, plus gives you a reason to travel. Yunnan has great options for the border hops on the cheap: Myanmar and Vietnam (visa available in Kunming) and Laos (visa on arrival) are right next door, Cambodia, Sri Lanka, Bangladesh, India, Nepal, Thailand (visa on arrival) are also close.

<comment><AUTHOR> That's awesome, I'm looking into it now. Thanks man!</comment></comment></comment></comment>


WeWork Parent Postpones IPO - <AUTHOR> https://www.wsj.com/articles/wework-parent-expected-to-postpone-ipo-11568671322?mod=rsswn <comment><USER2> So much wrong about this listing and company that I feel relieved to hear they are delaying their IPO. The corporate structure defied reason as did the concentration of voting power in their CEO, aside from the self-dealing and other ethical lapses which were apparent. I still don't know why this business is considered a technology play.</comment>


Ask HN: How to find a part-time programming job? - <AUTHOR> I'm currently looking for a new job. Right now I work full-time in an office, and I'm hating the lack of time I have. I can afford my expenses with a part time job since I split my rent with another engineer. I'd love to have some more free time to work on some side projects to eventually run my own business, and really just to de-stress.
I'm a game developer, and I've only worked here for a year and a half, but I look like I've aged 5 years since I started here.
So anyone have any recommendations on how to find a part-time engineering job? Remote is preferable but I've never worked remote before so I know that might be hard to find for myself.
I can't seem to find many jobs online that I'd like to work for...would be great to have benefits too, but I know that's rare for part time employees in the US.
(I am in the US by the way) <comment><USER2> I have worked part-time as a dev in the past but I essentially went from full- time to 3 days a week in the same company. I only did it for a short time. A lot of people warned me that sometimes companies and coworkers will expect you to do the same amount of work in the reduced hours, I think it is rarer in places that are used to people working part-time.

<comment><AUTHOR> Yeah...that's what I'm trying to avoid, and why I probably don't want to just go part time at my current job.</comment></comment>


Ask HN: Do you mostly browse to catch up or just for entertainment? - <AUTHOR>

I have about 6-8 sites that I always need to be fully caught up on. I'll check them a few times a day, and while I don't need to read every article, I need to at least look at the headline of every article up to the last one where I left off so I know I'm caught up. I'm working on a solution to this problem (skim.me, but I don't want it to distract from the question), but we're not sure how many other people browse this way. Are you concerned with catching up on specific sources, or would you'd rather just have content recommended to you and don't care if you missed any updates from any one specific source, so long as you see stuff that's interesting? Do you browse to catch up, or for entertainment? <comment><USER2> Hacker News recommends content to me. It's the only site that I look at every day. I don't worry if I haven't seen every HN headline, the site just isn't good for keeping up and the only way to win that game is to not play.

Once in awhile I'll look at a more news oriented site, like news.google or _rarely_ my region's newspaper's site.

So yeah, I like having things recommended to me, and I like the way HN does that for me.

</comment><comment><USER3> I like to skim the titles as well up to a certain point. It's always nice to know what's going and on and to try and learn new things. Makes for a good conversation starter if anything. If I miss a few days it's no big deal though. I won't try to go back and read all the content. I like content recommended to me to an extent. The upvoting and downvoting kind of takes care of that but I'm sure I miss some good articles.

</comment><comment><AUTHOR> Thanks guys. I wonder how many people look at stuff mainly for conversation reasons, as mburst was saying. Like, would you rather have stuff recommended based on popularity so you know what to talk about with people, or based on personalization tailored specifically to you?</comment>


New Startups Aren't Keeping Big Mattress Up at Night - <AUTHOR> http://www.bloomberg.com/news/articles/2015-03-12/new-startups-aren-t-keeping-big-mattress-up-at-night

<comment><USER2> They're merely in the early adopter phase.

The internet didn't destroy printed newspapers overnight, but one by one, they're finishing them off (in print and in organization).

The sad thing is when people don't work less when their costs go down but instead spend the freed money on something else, like higher rents or mortgage payments.</comment>


Using Twilio with Node.js - <AUTHOR> http://blog.twilio.com/2011/02/using-twilio-with-nodejs-by-dusty-candland-of-red27-consulting.html <comment><USER2> In addition to the raw XML generation done here, there's also node-twilio (<https://github.com/sjwalter/node-twilio>), which is IMO the nicest way to build Twilio apps on any platform.</comment>


EC2s getting harrassed by vulnernability scans from useragent Jorgee - <AUTHOR> I run a bunch of microservices on AWS Elastic Beanstalk. I set up alarms for anytime I start returning a large number of status codes and recently, I've been getting emails every 3-10 minutes all hours of the day.
Looking into it, its bulk wordpress/php related 404s from the useragent Mozilla 5.0 Jorgee, about 50-150 at a time. I don't use php so its not a problem, but the alarms are hard to get around. Don't want to cancel them and not know when something actually goes off the rails, but I can't afford to have my email blown up by bullshit.
First thought was just returning 200's but that's bullshit.
Suggestions and similar stories appreciated. <comment><USER2> I've experienced this and the 404 related emails on Elastic Beanstalk are indeed annoying, and it would be good if there was any easy way to turn them off just for 404s specifically. However based on my experience this will pass, it won't be like this forever so don't worry. And then it will come back, but then go away again. I haven't had a single email related to this for several months now. After it realizes there's no vulnerability (in my case I don't have php admin) then it seems to stop trying but I don't know how long before there will be new requests trying again.

</comment><comment><USER3> We ran into this at my shop. What we did is tuck away everything that isn't accessed externally in a VPC. Now they can't be reached by these scanners.

</comment><comment><USER4> I'd set up fail2ban on those machines to automatically block the requests.

<comment><USER5> I'm pretty sure you can configure fail2ban to automatically ban based on user- agent or url path. I would suggest banning any of the WordPress or phpadmin url links</comment></comment>


An Ancient Virus May Be Responsible for Human Consciousness - <AUTHOR> https://www.livescience.com/61627-ancient-virus-brain.html <comment><AUTHOR> Original paper here: [http://www.cell.com/cell/fulltext/S0092-8674(17)31502-7](http://www.cell.com/cell/fulltext/S0092-8674\(17\)31502-7)</comment>


Ask HN: What is the big idea with algorithms? - <AUTHOR> Firstly, I'm a non-CS major and am much unlike many of you mathematical whiz kids who make up this board, so having stated that, I hope you'll get a better idea for why this  book I just checked out at the library, Algorithms in a Nutshell [http://oreilly.com/catalog/9780596516246/], gets me so hot.
To me algorithms are as interesting as the formulas that makeup our Universe brought to us from physicists, granted they're both inspired from the same basis, which is to express a set of quantities algebraically that hold true as a solution to a problem. However, physicists and computer scientists are both working towards opposite ends, since physicists attempt to generalize a set of observations from the physical world into a law, computer scientists attempt to materialize a set of observations from the abstract world into a set of instructions, called an algorithm.
When I open this text-book's ToC it reads like a road-map into the beginning of the mostly unknown Universe of computer programming. I want you to briefly summarize why algorithms are so important, where they came from [their genesis], how you use them on a daily basis, whether or not they're more important than design, and what the formulas of the future will do for humanity.
[EDIT] More bluntly, summarize [and categorize, if you'd like] the evolution of algorithm design starting with insertion sort and ending at your heart's content [or AI]. <comment><USER2> [http://artemis.cs.yale.edu/classes/cs460/Spring98/contents.h...](http://artemis.cs.yale.edu/classes/cs460/Spring98/contents.html) is a very good resource on the parent science of algorithmic information theory.

AIT and computational complexity theory arguably underlay all other sciences. They allow us to define randomness (<http://www.cs.auckland.ac.nz/~chaitin/georgia.html>), pattern, probability (<http://www.scholarpedia.org/article/Algorithmic_probability>), inference (<http://www.wisegeek.com/what-is-solomonoff-induction.htm>), ignorance, and perhaps one day consciousness.

They allow us to prove, with absolute certainty, whether we are talking to a deity ( <http://scottaaronson.com/blog/?p=56>), and to prove that some questions will forever be beyond our grasp.

Even discounting Zuse and Wheeler's "It's from Bits" conception of information and computation as the basis of physics (<http://en.wikipedia.org/wiki/Digital_physics>), these disciplines promise to help us solve our hardest and most interesting problems by, first of all, telling us whether they are solvable at all, and if so, whether they are solvable before the heat death of the universe. Consider that Goedel, Cohen, and Turing struck down the Continuum Hypothesis from Hilbert's list of open problems, allowing us to abandon a futile line of inquiry and focus on other problems. Current developments in quantum computability theory may similarly strike down vast swathes of sterile ideas, directing us toward questions whose answers are solvable.

<comment><USER3> References and a sincere, open answer. You deserve a lot more karma than the sophomorish comment currently leading the thread.

<comment><AUTHOR> No kidding, this answer is as nearly loaded as my question.

</comment></comment></comment><comment><USER4> this suspiciously sounds like a final essay question for someone in college.

seriously, though, this is a pretty broad, abstract concept. an algorithm is, more or less, a set of instructions to solve a problem. they didn't have some sort of magical genesis, and everyone uses them on a daily basis.

<comment><AUTHOR> School's out bucko, I wouldn't stoop that low. :D

This is more or less a metaphysical inquiry into where computer science is headed. Algorithms + data begets design patterns, design patterns + objects begets...

<comment><USER5> If you want a good feel for this stuff, try downloading and going through this course, "NAND to Tetris": (Link is not the course, but a talk about it.)

<http://video.google.com/videoplay?docid=7654043762021156507>

The book is only $26, last I looked. The course software is all Open Source.

You'll see how digital logic is used to construct components like logic units and memory, which is then used to construct a computer, for which you create a computer language, which you then use to write an operating system, and finally, you program games on it.

This will then give you the wherewithal to _really_ understand Godel-Escher- Bach:

[http://www.amazon.com/Godel-Escher-Bach-Eternal- Golden/dp/04...](http://www.amazon.com/Godel-Escher-Bach-Eternal- Golden/dp/0465026567/)

If you want, you can read the book first, but then go through the course and read it again. The 1st time you read it, much of it will be lost on you, but the 2nd time, you'll have many Ah-HA! moments.

One key is Automata Theory. Understand that, and you can understand what you are trying to ask about.

</comment></comment></comment><comment><USER6> It's a little hard to tell what you're really asking, so forgive me if this isn't what you're looking for. Worrying about algorithms in the "mathematical whiz kids" sense is extremely important when you have to be worried about speed and resources. Take databases, for instance. Their search and compression algorithms are extremely optimized (by mathematical whiz kids), and they yield phenomenal results. If everyone had always been satisfied with a simple, straightforward solution, Google would be devastatingly slow and require an enormous amount of space more than it already does.

I've had to look into the efficiency of my algorithms when doing batch processing on massive XML files - I managed to cut run-time by 80% by paying more attention to my algorithm's efficiency.

On the other hand, if I'm just sorting 5 entries alphabetically for some table, it's better to implement a quick-and-dirty algorithm that will take an extra 2 milliseconds to compute, than for me to spend half my day worrying about it's efficiency.

So generally speaking - people designing low-level systems are very worried about their algorithms, with good reason: If their code is slow or wasteful, their platform can't be used. If you're designing a web app, you'd probably waste more time than it's worth if you delve into that. It's just a question of priorities.

</comment><comment><USER7> Very simply some problems are impossible to solve in a reasonable amount of time or at all; these problems may looks simple, but their complexity can explode.

For instance chess is relatively easy to program where as go is quite a bit more difficult. \</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>---

Here's a very good quote from wikipedia that might make it clearer:

The thesis is widely considered to be a good rule of thumb for real-life problems. Typical input lengths that users and programmers are interested in are between 100 and 1,000,000, approximately. Consider an input length of n=100 and a polynomial algorithm whose running time is n^2. This is a typical running time for a polynomial algorithm. (See the "Objections" section for a discussion of atypical running times.) The number of steps that it will require, for n=100, is 100^2=10000. A typical CPU will be able to do approximately 109 operations per second (this is extremely simplified). So this algorithm will finish on the order of (10000 ÷109) = .00001 seconds. A running time of .00001 seconds is reasonable, and that's why this is called a practical algorithm. The same algorithm with an input length of 1,000,000 will take on the order of 17 minutes, which is also a reasonable time for most (non-real-time) applications.

Meanwhile, an algorithm that runs in exponential time might have a running time of 2^n. The number of operations that it will require, for n=100, is 2^100. It will take (2^100 ÷ 109) ≈ 1.3×1021 seconds, which is (1.3×1021 ÷ 31556926) ≈ 4.1×1013 years. The largest problem this algorithm could solve in a day would have n=46, which seems very small.

<http://en.wikipedia.org/wiki/Cobham%27s_thesis>

</comment><comment><USER8> Understanding algorithms and how to analyze them will make you a better programmer. Should you memorize every algorithm and clever trick that others have come up with? I haven't. However knowing that there are different approaches with various space/time trade offs gives me options to consider when coding something up. It also helps make me aware of the pitfalls of doing things a certain way.

Could I whip up a tree balancing routine on a whiteboard on command? No! But, I'm aware that such algorithms exist and what situation I'd need to apply them to.

I think this is what you should shoot for. As for Algorithms in a Nutshell, if it is the book I'm thinking of then bravo. I like how the authors chose to present the algorithms using code and not the awful psuedo-code found in most algorithms texts.

<comment><AUTHOR> I think the space/time trade off is most interesting, given how impertinent it is in physics, and certainly constitutes a place for rethinking in how we approach mathematics and science on a whole.

</comment></comment><comment><USER9> To understand why algorithms are important, and how they are used, it might help for you to give up your mental model, described in your original question, of the link between physics and algorithms. They are not both attempts to represent some set of quantities. Rather, think in terms of physics as stating the equations (describing how the values relate to one another), and algorithms as methods for solving the equations (calculating the values).

So for example, physics describes the answer to "where will this spacecraft be five years from now?" while to compute a numerical answer you need to apply some particular algorithm (like a differential-equation solver).

Most of the algorithms in "Nutshell" are what you might call core-level methods of figuring things out. For example, the book describes different sorting algorithms. From your question, you sound more interested in what kinds of problems demand sorting (for example). For that, you might try a bigger-picture book, for example Steven Skiena's "Algorithm Design Manual." It goes into less detail about actual implementation, and more detail about what the algorithms do for you, and when you might apply them.

</comment><comment><USER10> When I first learned to program coming up with the algorithm was everything. I thought of how to move the data, compare it, and finally compute and represent the solution. As I grow more experienced the algorithms come naturally.

I now think in terms of rules, context and complexity. I mostly think about distributed algorithms and the key to me is always a small set of rules that all nodes must follow. Rules are generally reactions to events, involving communication and/or state changes. Much of the time the rules follow from some constraint, such as complexity requirements or limited information. There are often different possibilities so you consider the trade-offs based on your context. I approach computational problems in the same way. I figure out data elements need to interact and then come up with some reactive rules. The computation is the chain-reaction of those rules.

The algorithm follows from the rules. Essentially it is a formalization of the ideas into an iterative instruction framework. The algorithm can then be implemented on a computer by any competent engineer and may be analyzed mathematically (e.g. for formal proofs).

</comment><comment><USER11> For me, the study of algorithms is cs. Hacking is just a means of implementation. Also, I think it's a huge misconception that algorithms is all about math -- it's about problem solving in general.

As Dijkstra said "Computer Science is no more about computers than astronomy is about telescopes."

</comment><comment><USER12> It's part of the distinction between a master and a journeyman in the development trade. If you dont have a basic understanding of algorithms and the analysis of algorithms, you will never be a master.

</comment><comment><USER13> Not entirely related, but check out the concept of Kolmogorov Complexity. It should definitely interest you.

</comment><comment><USER14> I would guess 80% of software developers would be better off spending their time * learning business * improving their communication skills * talking with their customers

</comment><comment><USER15> _"I'm a non-CS major and am much unlike many of you mathematical whiz kids who make up this board"_

Are there any math whiz kids on HN? (other than cperciva)

There are many smart people on HN, but I don't think there are math whiz kids. This is a hacker forum, not a math forum like AoPS. Sometimes we discuss stuff like complexity and algorithms, but most of the time, we rant on Ruby x Python or why kids these days want to build social networks for dogs instead of sending astronauts to Mars, or why big corporations are evil and small startups rock, or why PG is a supreme master and every single essay of his is nothing less than the truth. We are such cool kids we even have our own hacker-ghetto slang... including hideous terms like "ramen-profitable" ;-)

I know a forum where there's even a Fields medalist, and that is on quantitative finance. Whoever says that HN is made of math whiz kids probably knows very little math.

<comment><USER16> What is a math whiz kid? I know there are a few professional mathematicians here -- professors, post-docs, etc.

 _...not a math forum like AoPS_

AoPS seems to be about math competitions. Math competitions have about as much in common with real math as the space marines from DOOM (demons, plasma guns) have in common with real marines (marching, painting stuff, acronyms). Real math is about building theories that are as general and powerful as possible, or making tools, or finding and solving interesting problems in the real world.

Math competitions are about how many reductive insights you can come up with in two hours' time while sitting at a desk you're not allowed to leave except perhaps to go to the bathroom.

<comment><USER15> I agree with everything you wrote. However, it seems to me that AoPS is populated with math enthusiasts, while HN is populated with hackers. AoPS is indeed mostly about math competitions, and yes, math competitions have little to do with real math, but just count the number of great mathematicians who performed amazingly well in the IMO: Terry Tao, Misha Gromov, Grisha Perelman, etc. My point was not that AoPS is about real math, but rather that it's more likely to have math whiz kids than HN.

<comment><USER17> choose any difficult profession and any highschool or college level competition, you can exhibit people who did well in both, does that mean one is the predictor of the other? I don't think so.

<comment><USER15> That's quite true. I try not to fall under the spell of the selectivity bias.

I know a bunch of math grad students who competed in the IMO and the Putnam, and I know another (smaller) bunch of math grad students who despize math competitions. It's a matter of personality, I guess. Some are problem solvers, other are theory builders. We need both.

All in all, the point was that math competitions, per se, attract math "whiz kids". Hence, AoPS should be populated by, at least some, math "whiz kids".</comment></comment></comment></comment></comment>


Do you really know why you prefer REST over RPC? - <AUTHOR> http://apihandyman.io/do-you-really-know-why-you-prefer-rest-over-rpc/ <comment><USER2> > Both RPC and REST use HTTP protocol which is a request/response protocol.

Neither REST nor RPC is tied to HTTP at all. I think the title alone of section 6.3 of Fielding's dissertation, "REST Applied to HTTP", [1] should be enough to convince anybody that they're completely orthogonal concepts, much less the rest of the actual dissertation. The Wikipedia article for RPC [2] also provides numerous examples of RPC implementations that never even touch TCP, much less HTTP.

REST is literally just transferring some state via a representation. RPC is literally just calling a procedure remotely.

Also, yes, hatred of expecting different behaviors from different verbs is irrational. Because verbs indicate actions, and different verbs indicate different actions. It works well in written/spoken language, and it works well in REST _and_ HTTP.

[1][https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluati...](https://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation.htm#sec_6_3)

[2][https://en.wikipedia.org/wiki/Remote_procedure_call](https://en.wikipedia.org/wiki/Remote_procedure_call)

<comment><USER3> _Also, yes, hatred of expecting different behaviors from different verbs is irrational._

To be fair, you've kind of rephrased her point into a strawman that's simply opposed to the abstract concept of verbs.

Most of the time, people understand URLs as a one-to-one mapping - each URL has only one meaning, one website. It's not until you actually start writing code to create or consume an HTTP API that you need to learn the concept of the different verbs. In spoken language you don't become functionally fluent with the language and then some time later have a new concept of verbs introduced. So I can understand why the idea that "actually a URL (the part that everyone sees and knows) can have multiple meanings based on this hidden parameter" can feel wrong.

<comment><USER2> In defense of the way I phrased that, here's the direct middle section of his tweet: "... different behaviors based on the verb..."

It's very very deliberately called an HTTP _verb_ , for a reason.

It's not that I expect the average person, or even a new developer, should know that HTTP verbs exist or that URLs and URIs literally locate and identify resources in a uniform way. The part that bothers me is that when you deliberately write a blog about the subject that other developers may see and take as credible, you ought to put more effort into making sure your information is accurate before publishing.

</comment></comment></comment><comment><USER4> But REST is RPC. I've read the article and the author basically defines RPC as a HTTP API that doesn't use the HTTP methods in a semantically correct manner but that's not what RPC is. RPC is any remote procedure call. It doesn't even have to be HTTP-based. Message queues are an example of something that's not RPC.

<comment><USER5> I agree with you. Too many get carried away with REST and don't think beyond HTTP.

I do appreciate the author's work here, I think the author was trying to help people clarify that REST/RPC don't need to be exclusive and that is helpful. All too often we encounter developers who want to sound smart and cool and state that it is "this tech" or "that tech" or NOTHING!

At a higher level of abstraction, representational state transfer should have nothing to do with HTTP semantics. It just so happens that we attribute REST with being related to HTTP semantics. But you could do REST with a non-HTTP protocol, if you wanted, why not?

Similarly, you can use a non-HTTP protocol in any other kind of framework for network based communication that you wanted...

And it just so happens that RPC is exposing functional, encapsulated units of code via network protocols and TCP/UDP sockets.

I remember trying to write my own network protocols for fun before over TCP and UDP sockets. Simple things like an echo service or a simple client/server application protocol. Doing that helps give one context for REST, RPC, SMTP, FTP, and more - semantics, concepts and frameworks over network connectivity.

The OSI model still matters. [http://en.wikipedia.org/wiki/OSI_model](http://en.wikipedia.org/wiki/OSI_model)

</comment></comment><comment><USER6> One point of doing REST instead of RPC is because you shouldn't re-invent the wheel. HTTP already has verbs and identifiers, so why create another set of verbs (the RPC methods)? REST is embracing HTTP to its fullest, RPC[overHTTP] is "just" taking advantage of HTTP's ubiquity across platforms.

[Edit: I don't mind having a few RPC-style endpoints in a REST API. The world's not a perfect square and sometimes things just don't fit the resource- driven model well. But for example, for performing logins (something which I previously did via "POST /login"), I switched to doing a "POST /sessions", because that's what a login it is: adding a new session.]

<comment><USER7> > _One point of doing REST instead of RPC is because you shouldn 't re-invent > the wheel. HTTP already has verbs and identifiers, so why create another set > of verbs (the RPC methods)?_

Because HTTP's verbs weren't created with arbitrary operations in mind, but for specific, HTTP-related tasks.

</comment></comment><comment><USER8> I actually prefer RPC. It's not very often I'm making a call to a server that I don't want to have complex logic behind. The REST paradigm doesn't fit that (though you can wedge it in).

REST GETs are fine for getters, and I generally like REST URLs because their prettier and don't have god-function smell like you get with SOAP.

But for commands, a POST with params to distinct URLs for each command works fine.

</comment><comment><USER9> REST as "representational state transfer" is a boolshit. The real reason it is popular - it allows to communicate via HTTP, just URLs everyone understands and many tools available, even web browser can be used.

If you remember SOAP - the crazy approach to web services promoted before REST, you understand the difference REST made.

The same way AJAX is not about XML, REST for me is not about "representational state transfer", but just about using URLs to request operations from server.

The original REST idea of using HTTP error codes and forbidding application to create its own error classes and error reporting convention just doesn't work. HTTP errors only meaningful for HTTP - a transfer protocol, not for arbitrary application.

The point of using different HTTP verbs - chaching. Don't do

       GET /deleteItem?itemId=456

because it's not guaranteed to reach the sever. Use POST instead.

So, I use HTTP URLs to communicate with server, and don't care to follow REST dogmas. It's more similar to what article calls "RPC" (actually RPC is more general term, in particular including SOAP).

<comment><USER10> Feel free to expand those explanations... :)

<comment><USER9> Not much to add.

The REST culture gives us some regularity. If we read github API, or google API or facebook API, we know what to expect - that they will use GET to retrieve an object, DELETE to delete an object and so on. It's good there is a convention helping to study new things.

Another good property of REST culture - it prevents people from building thick layers on top of HTTP. While not everything can fit into HTTP (at least error reporting, in my opinion; HTTP error codes are not enough), this culture helps to keep APIs simple.

<comment><USER11> Other than the verbs used, there isn't very much regularity. Try plugging a back end REST API into a front end framework. In my experience you always need an extra library.

</comment></comment></comment></comment><comment><USER12> I generally use a pattern like:

GET /api/resource

POST /api/resource/action

Where 'action' is something a bit more descriptive than 'PUT' or 'DELETE' or whatever. Kind of like an object-oriented api... I'm still always dealing with resources, but I have custom actions for specific use cases.

<comment><USER13> Why would you do this? It makes no sense.

By (mostly) adhering to REST patterns you get so much stuff for free. Other developers can quickly get up to speed quickly. Client libraries are easier to write. Things like Ember Data work out of the box. I agree that every now and then doing a POST to /logout is easier than doing a DELETE /access_token/23, but a consistent API is far more worth it.

<comment><USER14> the problem with HTTP REST verbs is that not everything can be (or should be) represented as a resource.

a simple example is a one-click payment + order action. you're creating multiple records in different tables - payment gateway transaction log, payment table, an order table, probably creating a customer record, sending email notification, logging a conversion, etc.

that sequence of actions does not adhere neatly to any HTTP verbs. it can be more clearly called "processorder" because it involves a lot more than creating an order record in a table. if you'd like, you can of course do POST /orders, but the nuance of what's happening is unnecessarily lost.

another example is a taking that order and marking it as "shipped". it is not a simple PATCH /orders/123 shipped=true. the front-end does not know all the fields that must be set in all the places on the backend. it is in fact a series of actions that take some data from the front, and some from the back and do a bunch of things that represent the setShipped() sequence.

HTTP verbs were designed for managing documents, for which they work well. They also happen to map well for direct db entries via CRUD. but trying to shoehorn them into all aspects of complex web apps is misguided. a true RPC is often what is necessary.

<comment><USER15> "Buy this" might create multiple records in different tables, but there is no requirement that one URL in a REST API corresponds directly to one record or one table. The REST API does not have to expose the entire sequence of under- the-hood actions. This does not somehow require RPC to address.

<comment><USER14> how would you differentiate a direct CRUD route with one that performs a lot of additional things?

PATCH /orders/123 shipped=1

what does this do? does it simply set a field or does it trigger a shipOrder() sequence that also sets that field? what if you need the ability to do both (eg: admin interface & customer frontend)?

I understand that in this case you can instead do something like:

POST /shipments order=123

but not everything has a record backing it that would yield to this pattern. the response to a POST is supposed to be a Location header of the created record, so in fact you do need some form of URI and record for the created shipment.

HTTP REST's multi-item and hierarchical item management are also very hacked- in and necessarily too chatty. You cannot return multiple Locations in a header, for example, when multiple records are created. Strict adherence to the purity of HTTP verbs and limits quickly degenerates into custom hackery above and beyond the RFCs for anything mildly complex.

<comment><USER16> I think some these statements aren't right:

> the response to a POST is supposed to be a Location header of the created > record

The HTTP spec says otherwise:

       The action performed by the POST method might not result in a
       resource that can be identified by a URI. In this case, either 200
       (OK) or 204 (No Content) is the appropriate response status,
       depending on whether or not the response includes an entity that
       describes the result.

> You cannot return multiple Locations in a header, for example, when multiple > records are created.

Again the HTTP spec allows you to manage this (though not in the header):

       10.2.2 201 Created

       The request has been fulfilled and resulted in a new resource being
       created. The newly created resource can be referenced by the URI(s)
       returned in the entity of the response, with the most specific URI
       for the resource given by a Location header field. The response
       SHOULD include an entity containing a list of resource
       characteristics and location(s) from which the user or user agent can
       choose the one most appropriate.

Source: [http://tools.ietf.org/html/rfc2616](http://tools.ietf.org/html/rfc2616)

edit: was quoting HTTP 1.0 rather than 1.1

<comment><USER14> thanks for the corrections.

but here is a perfect example of multiple ways to do the same thing. and the custom additions to HTTP REST begin: multiple locations in the body of the response. the fact that sometimes the headers are sufficient, but at other times, you have to just create your own API to fill in the missing functionality using the response bodies.

no me gusta.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> I prefer to call my APIs RESTish. That way, I can avoid never ending debates about whether some particular feature of my API conforms to REST.

<comment> ryan-allen Who would have thought that there's more than one way to skin a cat? Or maybe REST is the best chuck out the rest! Pun intended!

I like your approach because it avoids never ending debates.

<comment><USER17> How about PREST? Pragmatic REST?

<comment><USER15> Post on Hacker News, 2016: "Pragmatic REST is not REST at all"

</comment></comment></comment></comment><comment><USER18> One point that didn't get addressed in this article is the use of HTTP status codes to indicate the result of a request. REST encourages proper use of status codes – 404 for a missing resource, 422 for invalid data, 201 for successful resource creation, etc. – further enhancing the predictability of the API. How does RPC handle status codes?

<comment><USER19> Eh, sorta. Send an invalid body, say an unavailable product ID, or an invalid quantity. What error will you return? HTTP codes and REST might make sense for some simple scenarios (like managing files), but it breaks down fast otherwise. Shoehorning everything into the few codes HTTP has seems pointless.

<comment><USER20> 400, 422 (or even 404 if the product id was part of the resource URL). That's not shoehorning, that's using something which defines a crude yet semantically consistent granularity, that does not prevent having more detailed errors in the response body and/or additional headers. So I get a level of abstraction for free, increasing consistency in semantics and behaviour both inside my API and outside, easing debugging and allowing me to use off-the-shelf HTTP components (including curl) while leveraging common knowledge of the protocol across applications.

The pet peeve issue I have with RPC/HTTP APIs is that people keep reinventing HTTP on top of it, only badly (at which point they may as well use RPC/TCP). That's why I like REST/HTTP, because I can "reuse things" when the problem model fits well within that tool (and it very often does). If REST/HTTP becomes a constraint instead of an asset, then maybe one should not use either REST or HTTP, _and I 'm fine with it because that was not the tool for the job_.

This is a tool, not a religion.

</comment></comment></comment><comment><USER21> REST is great for CRUD, and easy from javascript/web pages, but it sucks for non-CRUD actions (like logout a user or reboot a machine), and it is not as friendly as RPC for consuming from client libraries.

I have designed both, and I find that the contortions you have to do to make your API RESTful is generally not worth it unless you're almost entirely CRUD and are mainly targeting the browser (and even then, you probably have a lot more nonCRUD actions than you think).

For everything else, RPC wins because you design it much like regular code.

Maybe the answer is just to use both, rather than trying to jam a square peg in a round hole.

<comment><USER2> I'd say the tricky part is modeling _state transitions_ in REST. Rebooting is a transition between states as is logout.

Instead of defaulting to RPC, I like to try a few things:

1\. Find some abstract resource that represents. POST to reboots to create a new reboot. In order to faithfully bring the resource into parity with the new state you've requested, the system reboots a machine. A GET to reboots should give you a list of previous reboots. Updating a reboot record might occasionally be necessary as well if an error occurred.

2\. Model the state transition as simply another state. "Rebooting," for example, might be a state you can transfer that represents on -> off -> on.

I'll admit they don't roll off the brain as easily as calling the "reboot" procedure, but I also typically find that it brings a good amount of positives as well. For example, the ability to create reboots brings with it the ability to get a record of those reboots pretty trivially (if you're storing requests).

<comment><USER22> My first approach for this is to POST to a reboot/ resource which gives you a reboot/123 ID that you can continue to do a GET against to see the status of the reboot (did it start OK? Is the machine back up?).

</comment></comment></comment><comment><USER23> The Richardson Maturity Model, as explained by Martin Fowler, is the only explanation of the benefits of REST that has ever made sense to me: [http://martinfowler.com/articles/richardsonMaturityModel.htm...](http://martinfowler.com/articles/richardsonMaturityModel.html)

And for what it's worth, I've only found value in levels 1 and 2, not level 3.

Also, this talk by DHH helped me understand how to organize an API by creating more nouns with a restricted set of verbs, instead of proliferating verbs on a smaller set of nouns: [http://www.bestechvideos.com/2007/08/12/railsconf-07-keynote...](http://www.bestechvideos.com/2007/08/12/railsconf-07-keynote- david-heinemeier-hansson)

<comment><USER16> Why do you not find value in hypermedia? Do you have tightly coupled servers and clients?

<comment><USER23> Yeah. Are there any examples of a generic client that doesn't know what data or API to expect? I don't know of any.

</comment></comment></comment><comment><USER24> In my experience, it's way easier to write client apps against a REST API.

If you look at frameworks like Backbone, you can basically create models/collections for a simple CRUD app just by adding some values to a declarative hash (URI, primary key, etc.). Because everything is so predictable, it's really easy to specify a default behavior.

Granted, you could certainly do something similar with an RPC API, but I still think it would likely be harder to generalize.

</comment><comment><USER25> A missing factor is fragility in the face of change.

RPC leads to fragile protocols. Adding arguments to a procedure or adding properties to a result can often break clients and in practice you update systems lock step.

HTTP can gracefully handle different API version requests to the same resource. REST clients are encouraged to take only what they need from the representation.

Also, I strongly disagree with the Totaling points section. Seems too "nice" to both sides.

</comment><comment><USER16> It seems to be that many of the comments on this and other API posts recently are by people who have never had to integrate with some else's "mostly REST but only when it suits me" API.

If the API you are writing has these features:

* you are the consumer as well as the author.

* no other developer is ever going to need to understand it.

* don't care about server/proxy/library support.

by all means don't bother with REST.

But if you are doing one/some/all of the above implementing a HTTP REST architecture is going to make your life and fellow developer's lives easier. That is what specifications are for, there to make things easier for everyone.

The thing I find most frustrating about these discussions is REST is such a simple architecture with a well thought out technical reasoning. Yet people happily ignore parts of it because of some unstated preference, and develop their own architecture which other developers then have to divine.

<comment><USER26> Let's say you have to integrate with my API that uses GET /user?id=1 instead of /user/1 , How have I made your life worse? Is it going to cost you any extra time at all to code it up?

<comment><USER27> People usually miss the references that should be encoded within REST responses, The hypermedia part. You should be able to call /user/ and get a list of users whith links to the specific users. This link will be in the correct http-format which means you can discover the api from one or a few starting points. This gets even more obvious when you try to fetch a sub- resource or call a "method" on a resource. Those links are encoded within the resource itself. That means when you get a user record it may contain links to things you can do with it (add an address or an extra email, get specific details etc). With SOAP it is only naming and there is very little recommendations about that.

<comment><USER26> I guess what I object to is this concept of discoverability. No matter what, you need documentation to discover these initial endpoints, so why not document the whole API? SOAP had mechanical discover ability with WSDLs but it didn't really work. The reason REST won was because it was simple for humans to understand, which means mostly that the documentation is simple to read. As long as the URLs follow some simple consistent pattern that developers can implement without convoluted effort it should be fine, no need to follow some rigid philosophy. If the documentation is missing some key actions I doubt most developers are going to go poking around hoping to discover undocumented endpoints, they'll probably end up contacting the developer to tell them they're API is broken.

</comment></comment></comment></comment><comment><USER28> Actually, the URL pattern doesn't define if your API is RESTful or not. You can use similar URL patterns in RPC too. This would be non-RESTful:

        POST /users/create
        POST /users/1234/read
        POST /users/1234/update
        POST /users/1234/delete

Also, in REST you don't have to use this URL pattern. Just make sure that your resources have their own URLs. In addition, resources don't have to map into your database. E.g.

       POST /new_address_due_to_move.php?customer_id=1234,

is RESTful, although a bit of a stretch. My line of thought is that if you would have a separate form in your web page, it should be a separate resource with it's own URL where the form data is POSTed.

</comment><comment><USER29> If you have a 1:1:1 relationship between database models, in-memory models and the REST endpoint, and the primary purpose of the API is to manipulate these entities, there's a reasonably strong stylistic benefit to REST style. Not all applications are like this, but many bread and butter CRUD apps are.

</comment><comment><USER30> Hmm. Seems to me that this actually relates well to the object-oriented versus functional programming "debate" \- REST deals with things (like OO), RPC deals with actions (like functional).

But, in my experience, most requests consist of a "thing path" \- host, resource; and then some "function" \- get, update, other. POST is then the '=' \- it's still a function under the hood, but because of it's commonality and interaction with language, the syntax is a little special.

In which case (and this is what I see in the APIs I most like) "the right thing to do" is to combine them, where you have pure REST when you're interacting with the object, but use RPC style when you're interacting with the object's actions.

Let's say I have some machinery exposed through an API, you might do:

GET host.com/machines/1 -> {"machine":"mixer","state":"off"} POST host.com/machines/1?state:on -> 200

because I'm interacting with its state. But if I need to interact with its functional actions:

POST host.com/machines/1/mix?substance1=h20&substance2=c02

it makes more sense to phrase it as an action. "I want you to start doing this". You could also phrase as a request for a state transition: POST host.com/machines/1?state:mixing&substance1=h20&substance2=c02

but (to me) that seems way weirder, generally.

I've got to go, but I think the answers change you go from physical resources to virtual ones, say, things that process information -

GET host.com/stock_analyzer/6/analyze?ticker=GOOG

where you might control state variables regarding the analysis algorithms using a REST-style.

Thoughts?

<comment><USER31> > REST deals with things (like OO), RPC deals with actions (like functional).

I think it's the opposite: REST deals with data, while RPC calls an operation that has side effects on some (potentially) unknown state.

Not arguing that one is better just offering my thoughts on the analogy.

<comment><USER32> That looks to me like you both agree. Things==data and actions == "calls an operation"

<comment><USER33> The main problem is that function != action.

<comment><USER34> Exactly. Action is imperative, not functional.

</comment></comment></comment></comment></comment><comment><USER35> > If a user want to stop using your service, you'll do this (not so obvious) > call:

> DELETE /users/1234

No! It would be

      DELETE /sessions/12345

or possibly

      DELETE /users/1234/session

or even

      DELETE /users/1234/sessions/3

in the case a user can have more than one concurrent different sessions (this is actually a fairly common case for the application we do were I work. We don't use http for this though).

Unless you actually want to permanently stop the user from using the system, in which case

      DELETE /users/1234

would be the perfectly obvious choice.

</comment><comment><USER36> The OP has essentially used circular logic: RPC is as good as REST because I know how to use it to address the issues that REST addresses (which I doubt, incidentally).

This to me is like arguing that object-oriented programming isn't really any better than procedural programming because I know how to write well-structured procedural programs. This is completely beside the point, which is that procedural programming as a style _tends_ toward balls-of-mud programs (to simplify things), and object-oriented techniques were conceived of in order to address the characteristics of procedural programming that are the cause of this tendency.

I view RESTful API programming in a similar vein: RPC also has negative tendencies (such as the creation of fragile protocols), and REST addresses many, if not all of those. Most of the time for more people, RESTful techniques will lead to better service and API design than will RPC, just like for most of the people most of the time, object-oriented programming will lead to better programs than will procedural programming.

</comment><comment><USER37> I'm amazed that when talking about RPC that schemas never came up. Schemas are probably my favorite part of RPCs. Let's say you have multiple services that need to communicate, but testing interoperability between the services is tricky. RPC type enforced schemas (interface definition language (IDL)) are great for this because the schemas provide guarantees that the services are communicating correctly. If a system starts seeing exceptions about IDL/schema errors, then you know right away that things are broken. Writing tests that can assume that RPC method calls will be enforced.

Another thing that struck me strange about the article is showing the RPC urls. When I was using Thrift, I never needed to think about URLs. I just needed to make sure that I was calling methods correctly.

I think RPCs are a good fit for organizations looking for a way for their service based architecture to communicate. I don't really like exposing RPCs as a public API or for web clients to interact with.

</comment><comment><USER38> I really like REST most of the time, but I do have some complaints about Rails' implementation of it. I wrote about them a few years ago:

[http://illuminatedcomputing.com/posts/2011/07/restless- doubt...](http://illuminatedcomputing.com/posts/2011/07/restless-doubts/)

Basically, after form submit errors your location bar still says /widgets or /widgets/1 rather than /widgets/new or /widgets/1/edit, so bookmarking that page, or "like"ing it, or Ctrl-L + <Enter>ing are all broken. I'd much prefer a redirect back to the correct URL.

Also the distinction between "create" and "update" can break the back button, if the user creates something, then clicks back to edit their submission (because submitting a second time will create a second thing, not update their original thing). That's not Rails so much as REST in general.

<comment><USER39> Not sure if I 100% understand, but it sounds like maybe you want to rescue the exceptions you can think of explicitly, then redirect_to previous_thing and return

<comment><USER38> Exactly. Something like this:

        if @foo.save
          flash[:success] = "Saved"
          redirect_to foos_path
        else
          redirect_to new_foo_path
        end

The standard pattern is to `render 'new'` rather than doing the latter redirect. So I'm complaining that my preferred way isn't "blessed" by the Rails community. Also you need a trick to keep @foo.errors in between requests and load it up in your #new method the second time around.

</comment></comment></comment><comment><USER40> I like how when building REST API servers and clients there are standard components that just works. The entire API in the same format means it is easy to write a DSL across the entire API configure each endpoint - such as row level and field level permissions, pagination, filtering. If you have a well designed RPC you have the same benefit, but except with REST - you can reuse someone else's work because the design is the same. It literally takes 20 seconds to change the _/ user/_ endpoint so:

1\. Non-authenticated users can create users, and see a list of users with details that are public.

2\. Authenticated users can view their own public and private details and have read/write access to most fields except _is_staff_.

3\. Staff users have full permissions for users that belong to the country they are managing.

4\. Superusers have access to everything.

Without the benefit of DSLs this would take hours to write all the if/else statements and unit test them. It would be a nightmare to do the same for all your endpoints. I assume you can write some abstraction functions to use for all your RPC endpoints but it'd be easier to reuse a library from past projects that had the same REST API design.

Example:

Row level:

        permission_classes = [
            Or(And(Or(IsOwner('id'), IsStaff), IsUpdateOnly),
                And(AllowAny, IsReadOnly),
                And(AllowAny, IsCreateOnly))]

Field level:

        is_public = And(IsActive, Is('is_public', True))
        fields = {
            'display_name': [],
            ('is_active', 'password', 'email'): [
                Or(is_staff_or_owner, IsCreateOnly)
            ],
            ('full_name', 'slug',): [
                Or(is_staff_or_owner, is_public, IsCreateOnly)
            ]
        }

</comment><comment><USER41> I started developing network apps before REST existed -- probably like many people here, that wasn't long ago, SOAP, various things like RMI and then XMLRPC were things. SOAP was never good anyway, deeply buried in standards committee goo. But there are still things I miss from these things. When I found XMLRPC after doing all these things, it was very much a "WOW" moment. (JSON of course, with it's definite differences between maps/hash-tables and lists, is greatly superior to me).

A generic problem with REST APIs is they all handle collections, associating items with subcollections (including establishing and removing 1-to-many or many-to-many relationships between existing objects), query strings, authentication, and pagination very very differently. Not all APIs are discoverable either, many don't do structured error codes. Thus to talk to one, rather than just using _client-library_ , more work has to be done, often repeated work in multiple languages. Lots of REST APIs aren't well discoverable and rely on special logic to form up URLs, and many have weird verb pollutions - modelling a long running job for instance, I've typically have done as posting a job descriptor to a job collection, because the standard verbs don't really apply.

All being said, I prefer a nice broweseable REST API, but despite the accursed "XML" in the name, XMLRPC was easy - there were bindings in multiple languages and it was easy to ask an API what methods were supported. Problems came in the undefined parts - like whether "None" could be passed, and so on.

I can design and build some very elegant REST APIs, but the clients DO have work to do, every time. A good example for me was trying to write to GitHub's API, and then being angry at the way pagination was overcomplicated and URLs were not discoverable. (It might have gotten better).

BTW, if you are doing Python and want a GREAT foundation in pagination, discoverability, and so on, I recommend Django REST framework. One catch is you may wish to extend some of the serializers to return URLs relative to other URLs.

I don't think RPC is evil so much - over HTTPS and backed by a good webserver, and done so that it's stateless (something a pre-forking webserver (esp with MaxRequestsPerChild in play in Apache) forces you into, not so much REST protocols all by itself), I think it's just not socially acceptable.

So statelessness good, having to write client-specific "flavors" of REST, well, it's just reality.

(In other news, I'm disappointed all my He-Man figures got sold in the 80s so I can't illustrate tech cartoons with them, well done)

<comment><USER42> _> SOAP was never good anyway, deeply buried in standards committee goo._

IMO SOAP in its very early days was actually fairly pleasant, at least when compared to the existing alternatives (things like COM and CORBA, which, ew). XML-RPC was also nice, in a "keep it simple, stupid" kind of way.

Then of course SOAP crushed XML-RPC, the crew of the USS Enterprise got their hands on it, and the rest is (depressing) history.

<comment><USER33> I've met SOAP when IBM was already pushing it, thus I may have completely missed the early days.

But I never even imagined I'd hear somebody say SOAP was more pleasant than CORBA. Yes, working with is CORBA barely better than hitting your foot several times with a hammer, but relative to SOAP, it's a breeze.

Anyway, it's kind of depressing that even now the best RPC we have to show is REST. It's a problem that looks so simple from a distance, why can't somebody build something really great here?

</comment></comment></comment><comment><USER43> This seems to me to be a debate between equally usable technologies. The differences between REST and RPC are slight enough that it won't make a big difference which you go with. To spend too much time on this would be bike shedding.

<comment><USER44> Tabs vs Spaces

Emacs vs Vim

Destined to become one of the great debates of history.

</comment></comment><comment><USER45> I might be behind on state of the art these days...but my current api has no GET requests, everything is a POST. So in that term, we are not restful.

We had a couple of problems with GET requests: all of our data ended up in the url (we have too much info that has to be passed, we stopped working on some browsers), and the data returned could be cached (which is a HUGE problem for us).

Now, POSTs can also be cached, but there are easy ways around it...you can do the same thing with a GET, but that means adding more information to the url.

Anyway, one we got to the point of forgoing all GET requests, we ended up just doing everything with a POST for simplicity.

<comment><USER6> I did the exact same thing in a project of mine. We're shifting away from that and put our data in cookies, so we can cache some of the things our API send out.

<comment><USER46> You can also use localstorage these days. It's great not having to send data on every request.

</comment></comment></comment><comment><USER47> I don't think GETs should ever change state. I'm fine with all other operations being POSTs though. If nothing else it provides compatibility with clients that don't support all the HTTP verbs (yes there are some)

<comment><USER48> How do you manage big queries with GET?

<comment><USER49> By query, are you referring to the querystring/url size?

Practically speaking, I don't know if I've ever had a querystring that was effectively too large, busting some browser-determined limit. If you did, you might as well use a POST instead of GET, because the request is unlikely to be cacheable (I'm assuming the reason its such a large string is that you're serializing a large form of values or using the querystring to persist state in some way [protip: this is a bad idea]), which is the main reason to prefer GET for the request. POST (according to HTTP semantics, _may_ have side effects, but is not _required_ to have side effects).

IMHO, the choice between HTTP verbs beyond GET vs everything else is mostly bikeshedding. As a convention its fine, but there aren't a lot of pragmatic technical reasons to go with one over the other (referring to PUT vs PATCH vs POST), despite the HTTP semantics.

<comment><USER48> No, it just was a very flexible data-retrieval API and the query strings just could get rather big.

</comment></comment></comment></comment><comment><USER50> I prefer REST for mainly aesthetic reasons: the URLs are pretty, and in Rails I can handle different HTTP actions in the same method, which usually ends up being some clean code:

      def index
        if request.put?
          update_stuff
        end
        # get/put render same response content
      end

One of the unexpected benefits of intercooler.js has been that I can use REST- fully designed end points for my html-partial endpoints, and it all just "looks right", even though it isn't a traditional JSON API.

</comment><comment><USER51> Is it correct to say that POST is not idempotent? Sometimes it is, and sometimes it isn't. Maybe it would be more accurate to say there's no guarantee that it's always idempotent.

<comment><USER52> POST is used to create resources that don't already have identifiers. So, if you're repeatedly submitting that form, your request is creating distinct resources on the other end. If the resource already exists -- if it has an identifier -- you'd use (an unsafe, but idempotent) PUT to replace it.

</comment></comment><comment><USER53> This is purely focusing on it from the API level. REST is an architectural style. This comparison seems like it is entirely missing the point.

</comment><comment><USER54> I prefer REST because one way fits all usages:

GET /resources, POST /resources, GET /resources/id, PUT /resources/id, DELETE /resources/id

Five routes for one resource type. If you need more resources, you nest your URIs. Why would you need POST /deleteResource?idRes=id when you can just DELETE /resources/id?

Code reuse wins.

<comment><USER55> IMO the biggest challenge here is cases that doesn't fit in. What if you want to create or update multiple records in a single operation, for example. There are ways, namely additional batch resources, but structuring that is your problem.

</comment></comment><comment><USER56> I would argue REST wins on beauty, because it continues to follow the intent of a URL -- you can _locate_ the resource based on the URL. In RPC, the query parameters break the URL concept a bit by including location data in the parameters rather than in the path.

<comment><USER19> Seems like you can easily convert, if you want positional parameters. ?id=1&foo=2 just becomes /1/2\. I fail to see how that really matters from the final client or server code.

</comment></comment><comment><USER57> Many public apis are REST based but do have some RPC actions with url-based HTTP APIs. Sometimes it isn't either or.

For example an API that allows you to get users might also have a job resource or action to perform RPC jobs on the server from a manage api path or similar.

</comment><comment><USER58> My honest feeling is that the argument is kind of moot because people will use a combination of the two as necessary.

</comment><comment><USER59> I think Rest works best in dynamically typed languages as it can be a little less strict on format. I think in typed languages RPC could work out better as you can filter out bad requests quicker with a stricter format. I also think RPC tends to be more brittle to changes just like typed languages :)

</comment><comment><USER60> Because I can test and debug without requiring an enourmous environment set up.

</comment><comment><USER61> Because it's more straightforward.

</comment><comment><USER62> Isn't REST is a way to implement RPC?)

</comment><comment><USER63> my god that site is unreadable grey on grey</comment>