To paraphrase Noah Stokes-I think it was an episode of ShopTalk-he mentioned a CMS is really just an interface to a database of some kind. The real headline about headless IMO is it gets people thinking about decoupling their content from the presentation layer. (There’s other technology too.)īut for the rest of us? The web is slow enough as it is, do developers really need another abstraction layer-especially one as verbose as HTTP? If your view layer is so awful that it can’t grab what you need, based on what you model gives you, REST really isn’t going to help you. Or if you need to serve content into an app. ![]() If you’re NPR where you have multiple servers feeding content to affiliates, hell yeh a REST API is going to be invaluable. I’m not sure I’m cleared or qualified to explain them though.įor the “average” website, I can’t see a headless setup adding any value, just more complexity. I’ve seen some implementations and hear tale of widespread usage across major publications. Listen to a whole conversation about thisĭave Rupert, Jeff Eaton, Matt Dennewitz and I talked at length about this on ShopTalk. If you wanted to digest WordPress entirely through the API, that’s possible. WordPress is certainly a “regular” CMS in that is absolutely has the concept of views, but it’s not required that you use those views. We have a tutorial on the WordPress REST API that might be of interest. Can you use a “regular” CMS as a “headless” CMS? Server side code can read and digest data from an API just as well as client side code can. Oh great, more sites that only work with JavaScript. Just because it’s an API doesn’t mean the views using it are client side You didn’t have to know this new thing was coming along, your data is already ready-to-travel. So now, if you wanted to, you could use whatever system they have set up to write an app, use the network access, and get your data over to it to use. The company that makes it allows people to write apps for it, but it doesn’t have a web browser. Maybe it’s a little implant in your wrist that projects a screen onto your forearm. You don’t even know what the next THING is. I’m not qualified to give advice there, but it’s a pretty easy thing to web search and read about, as well as look at reference implementations. The URL structure and query params and all that would be up to the CMS and in all likelihood be “RESTful”. In a headless CMS, access to that data would be a URL endpoint like: But those things aren’t “first class citizens” of the CMS. ![]() Or you could write queries into the data storage to get what you want. You could probably write a view that outputs like an API. If you want at that data, the only way in is using the functions it provides. Perhaps in a regular CMS, the only way to get at the stored data is functions it provides. The “head” (that we are chopping off! eww!) is the display or “view” part of a CMS. Progressive enhancement says “let’s make the functionality of this site work no matter what.”ĭesigning for accessibility says “let’s ensure everyone can use this regardless of their capabilities as a person.”Ī headless CMS says “let’s not tie our data to any one way of doing things.”Ī “headless” CMS only shares the first two ![]() Responsive design says “let’s let our design and media accommodate as much variation in screens as possible.” How are we going to handle bringing Our Stuff™ all these different devices/screens/inputs. It’s very related to The Big Conversation™ on the web the last many years. Have you heard this term going around? It’s quite in vogue.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |