BREAD, not CRUD

Several developers have asked me what “BREAD” means in web applications. Most everyone knows that CRUD is “create, read, update, delete,” but I think that misses an important aspect of web apps: the listing of records to select from.

I don’t recall where I first heard the term BREAD; it stands for “browse, read, edit, add, delete”. That covers more of what common web apps do, including the record listings. It even sounds nicer: “crud” is something icky, but “bread” is warm and fulfilling. That’s why I tend to use the term BREAD instead of CRUD, especially when it comes to Solar and action-method names in the application logic.

Update 1 (2008-08-21): Wow, lot of traffic from Reddit and Y-Combinator on this one. Be sure to check out my post on Web Framework Benchmarking, and of course the Solar Framework for PHP 5.

I see a couple of comments saying that “browse is the same thing as read, it’s just a special-case of read.” I can see where that would be true, in a limited way. Using similar logic, one could argue that “add” is a special case of “edit”, it just happens that the record isn’t there yet; and then “delete” is another special case of “edit”, you’re just editing it out of existence. So that leaves you with just Read (one/many) and Edit (existing/non-existing/out-of-existence).

I think that takes things way too far. 😉 The special cases of “edit” are *so* special that they deserve their own logic. I think the same thing applies to “browse” — it might be a special case of “read”, but it’s different-enough to deserve its own place.

Update 2: Matthew Weier O’Phinney refreshes my memory — he mentioned the term to me years ago in a discussion about his PHP port of CGI::App. Thanks, Matthew!

Update 3: I said above that you could reduce all operations to “read” (with 2 cases) and “edit” (with 3 cases). It occurs to me now that those correspond to the way GET and POST are most-widely used. So maybe it wasn’t such a silly argument after all. 😉

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

22 thoughts on “BREAD, not CRUD

  1. Love it! Now I just gotta commit to memory — this is exactly what I keep trying to tell people; no matter the workflow, and the content, these actions are pretty much it.

    Design your API accordingly. It’s not that hard!

    – Davey

  2. Brilliant. CRUD never has sat well with me. I think the order of operations is even better.

  3. […] From Paul m. Jones “I don’t recall where I first heard the term BREAD; it stands for “browse, read, edit, add, delete”. That covers more of what common web apps do, including the record listings. It even sounds nicer: “crud” is something icky, but “bread” is warm and fulfilling. That’s why I tend to use the term BREAD instead of CRUD …” […]

  4. I don’t think it’s necessary. Everybody already knows about CRUD anyway, and ‘browse’ is no other action physically than ‘read’. If you want to separately identify those, then the next thing would be to add Print, Render, Export, Import etc.

  5. It does not stand in the way of CRUD.
    I use Index + CRUD. Sometimes additional Search (but preffer include that in index).

    P.S. index + CRUD = iCrud. Hope Apple won’t see that 🙂

  6. I don’t see the value of the added ‘Browse’ also, but if you don’t like CRUD, perhaps DARU or RUDA sounds better to your liking? (-;

  7. Well nice to to know,
    how do i call it if my applications only have an [S]earch [E]dit and e[X]tend function ?
    I think that would be even more “warm and fulfilling. ” than BREAD 🙂

  8. ABCD: add, browse, change, delete.
    Easier to remember and also more logical. Application’s functionality starts from ABC..

  9. Ivo, I would consider browse and read to be two different actions. read being viewing a single entity, and browsing being viewing many entities at once (and likely paging through them). There can be a lot of overhead saved by not doing things like loading whole entities into memory when you’re just browsing, so it can be worthwhile considering these as different things when you start out

  10. A collection of records (resources) can itself be a record (resource). Browse is just Read applied to a collection—and nothing stops you from paging and/or filtering in read itself (multi-page articles on a newspaper site, for instance).

  11. I think you heard it through me, during one of our conversations at php|tropics. I first picked up the term via CGI::Application — the term BREAD was used commonly by users of that perl module, and I adopted it when I ported it to PHP. I personally prefer it over CRUD for many of the same reasons you state — it’s more atomic, and, as you note, _reading_ is not the same as _searching_ or _listing_ records.

  12. Love it, although it doesn’t only apply to web apps, but any data management system. I will definately be using this term from now on 😉

  13. I’m happy to find Solar PHP Framework. I can understand power of BREAD but I met with BREAD on python with Django Framework. It is awesome. I havent tried Solar, I hope it is good but I use zend framework on php. But after meeting with python, I’m just using django.
    if you want to see BREAD, look django framework

  14. […] you previously generated. Doing so will automatically create the actions and views for a complete BREAD application. As I get more familiar with all of this, I will post some more info. Possibly related […]

  15. I have just discovered the BREAD-S concept. This is exactly what I was looking for as a feature and naming in a framework. It’s stands for “browse, read, edit, add, delete and search”. For me it obvious that CRUD and BREAD sounds and are different things. The first naming is development oriented (CRUD), and the second one is more application (user) oriented (BREAD).

  16. How about BREADS [Browse, Read, Edit, Add, Delete, Search] That would complete it…

    🙂

Leave a Reply

Your email address will not be published. Required fields are marked *