So we're going to talk about services in Drupal 8. And Drupal is in general. We're also going to talk about just services.  How many people know anything about play with Drupal 8? And yeah, so what we're going to cover is actually what the services are, a bit of history, a bit of definitions, I guess. So a bit of theory, bear with us. We'll also pack the presentation with a few examples.  So to actually sort out any confusion or anything like that. So I guess that's what I basically got. And then we'll actually see a couple of presentations, couple of demos in Drupal 8. We're also going to do a birds of feather session tomorrow. There's more info on that in another presentation. So this is Jay. My name is Vladimir. We both work for Technicrad. If you didn't come say hi yet to us, we have a booth down there. Come and say hi to our guys. Talk about Drupal. We're all pretty friendly. Oh, most of us. There's a few that may not be. But you can also chat with us on Twitter, go to our website. So we actually want to take a trip back in time, not in the future, because I think that was in the previous session in the main auditorium. So we're actually going to go and see what the internet was like before. And the best way to do it is actually see what Drupal was like back, say, in something like 2002. So if we go back in the internet, this is 22nd of January 2002. And this is a snapshot of Drupal.org back then. So if you haven't used Wayback Machine before, go to archive.org. You'll see our websites look like. And this is actually quite a modern website compared to that. If you go, I think they have some of the US websites from back in 1996. And basically, if we take this moment of time when internet was pretty much publicly accepted, widely used. So basically, it started as a click by click navigation. And going into 2000, that's what it was like. And basically, the format people use was HTTP. So basically, single request and get the information back.  And eventually, once we get to current days, it's a bit more complex. So we know what Drupal is like at the moment. You actually know what Drupal.org is like at the moment. It's becoming so big, it has its own flow at DrupalCon North America. So it's the whole flow just dedicated to one side, Drupal.org. So as internet became more complex, the data became more complex, people needed new ways, new ways to treat data, to get data, and to interact with that. And that's basically where services kicked in. So the technology that's responsible for the majority of the services called Ajax, which stands for Asynchronous JavaScript and XML. And basically, once click by click navigation became relatively obsolete, so now that Ajax is responsible for that actually being loaded on the back end, while the user is actually interacting with the web page. There are different variations of that, but it's basically the model. So actually, if we're talking about web services, so web services is actually a protocol of the conversation between two machines or two computers. So there are strict requirements usually associated with it. And the most popular protocol is used for it is HTTP. So basically, when you go and type HTTP in your browser, that's what you get. So the initial request is still basically getting this page in the browser and get all that information to log to the page. Formats vary, and we're going to take you through a quick history of the formats that were there before and why there are formats that actually became popular and still are there. So you actually know what you're talking about. Next time you're talking about Drupal services in the core, you'll know what it actually means. Usually, also, to actually have a conversation between two computers, you actually need to have some sort of rules. So APIs, which is application programming interface, usually responsible for that. It kind of goes back into the rules, so actually requirements and rules. That's what machine needs to communicate. Now we go into history. So the original protocol for communicating between two computers was EDI, or Electronic Data Interchange. It was used since the 60s, so even before the internet was there, so two machines were communicating basically as simple networks or simple prototypes of the network were used in EDI. It was documented and standardized in 1996, so 30 years it was actually after it was used, but it was used in different variations again for years. It's strictly for method messages, and basically it was designed for large-scale e-commerce, but it was quite handy so people actually start using it for different sorts of communication. And if you actually want to talk the language, that's how it looked like. Very user-friendly. So if you want to have a conversation in EDI, that would look something like that. So then the protocols start getting evolved, and basically people said, OK, there are some downsides of the actual using the EDI. So remote procedure call, it's basically farther of a lot of stuff we're using today. It was born. I'm not going to go into details, but it actually was based on the DCE protocol. It was more function-based, so rather than seeing one line of bunch of letters, you have no idea you can see the function. So one function calls another, so it says, give me list of lectures, something like that. So a bit more user-friendly, a bit more better for humans to understand without going too much and saying, can you explain to me what it means? It actually became popular thanks to Linux, but Microsoft, as usual, came along and quickly adopted it to its own format and call it MSRPC. And a lot of stuff that actually came during the 90s on Microsoft platform, like OLA architecture, if any of you developed for Microsoft technologies or Windows back in the 90s or early 2000s, you're probably familiar with that, either DECOM or OLA architecture. So they all were based on this language communicating between two machines. Then Corba came around. One of the guys, it actually was alternative to RPC. So I think it was founded around early 90s as well. So it was common object request broker architecture that was Corba stands for. And it was also basically just a different communication language between two machines. If anyone developed here for Delphi or C++ Builder, they used Corba heavily. It was powerful, maybe too powerful, but very complex. You actually have to spend lots and lots of time to actually understand how Corba works and then tie it into a programming language you were using. So there were a number of efforts to simplify, and one of them came from Java's AMI interface. They come up with inter-op protocol to actually make it simpler. There were a number of attempts, but usually the complexity lead to the point where each company would develop their own language to communicate, which basically just segregation, segmentation over Corba itself became too hard. So again, as I said, there were one of many attempts to actually simplify it, but eventually to result in XML. OK, so XML. I imagine most people here have worked with XML before. Can I get a show of hands? Who has? Yeah, yeah, so we've got everyone. So XML, Extensible Markup Language was formed out of SGML, which stands for Standard Generalized Markup Language, and was built to be simple, readable by both humans and machines, as well as be generalized, so used for multiple purposes. It largely differed from EDI and other binary format-based systems due to being plain text, and when formatted as nested tags was easy to read for humans. So it was the multiple uses that it was intended for. Covered things like XHTML, which is used by your modern web browsers, and the data transfer of XML was also ideal in many cases because it had strict formatting rules. It was easy to validate if an XML snippet is coming back improperly represented to what you expected with your data. And as a result, it quickly became one of the most common formats for web services messaging. So with the emergence of XML, a massive number of XML markup languages came about. And these languages included, whoops, can you go on the next one? Sorry, I'm just losing my spot here. So these languages, here's an example of XML. As you can see, it's descriptive notation. So you can see how you've got your note to heading body to describe your messaging format. And it's really quite easy to read. I'll just move on because people are already aware. So from that, quite a few standards and languages emerged. You have XML RPC, which stands for, extensible markup language remote protocol callback, oh, sorry, remote procedure callback, protocol. Yeah, there we go. And without getting too in-depth, it basically encoded objects and data structures and uses HTTP to transport the data over the web. Then we have Atom and RSS, Atom standing for Atom syndication format and RSS for rich site summary. I know that there's also another definition, which is really simple. Somebody can help me out on that one. Syndication, there we go. And basically, the XML-based languages that are used to publish frequently updated content and then an RSS reader would interpret that information at the other end and would basically automate the process of checking for updated content from the user. And finally, SOAP, which is simple object access protocol. Who here has worked with SOAP? Who here hates SOAP? Yeah, so we've got a large number of people. SOAP, personal opinion, it's really difficult to work with. The documentation is massive, but it became extremely popular. And the reason being was that it was based on XML-RPC standard, but it took it much further. You can actually compare the docs between XML-RPC and SOAP and it's a huge difference, which in some ways was a benefit because it extended so much more functionality, but in other ways, it was just a nightmare to try to get your head around. And at the time, it was actually a revolution in web services. It was the foundation of a whole set of web services known collectively as WS-Athbrisk, which became known as web services, everything. Anyone who's picked up or looked at a wisdom file or any other number of files in that relationship would probably duck their head for cover just because it can be so complex. And I'll also, bit discreetly, I'll add that SOAP's lost quite a bit of its traction to REST and other XML standards, but it's still very heavy in enterprise applications. So mainly your .NET, your Java, and especially those requiring computer-to-computer communication. So moving on to something more enjoyable to work with is JSON. So JSON stands for JavaScript Object Notation. And I imagine everyone here has worked with JSON or knows what JSON is. Can I get a show of hands? Yeah, okay. Do I stop asking the silly questions where everybody's done it? So JSON is currently stealing XML's thunder. And surprisingly, it was actually introduced at a similar time to XML. It was introduced in the early 2000s, but it really didn't pick up until we hit sort of the mobile revolution. And the reason why is because JSON was able to transmit smaller messages. Essentially, you didn't have all the notation markup that XML had, and with the smaller sizes, it also equated to quicker speeds of the transmission of the data. And also, another thing is bandwidth. So with the evolution of mobile devices, bandwidth became an issue, particularly if you lived in Australia with our internet standards. And from there, like XML, JSON is text-based and human readable. So the final thing that it did offer when it came about was that it was a stateful, real-time, server-to-browser communication. And it didn't have the need for any sort of additional browser plug-ins, such as Flash or any Java applets. And that there is just an example of JSON. Those familiar with JavaScript, and you all are familiar with JSON, would recognize that. It was just so much simpler to communicate and to implement and to work with. We're going straight into it. Yeah. Yep. All right, so just a bit of a funny example. Who uses Spotify? Not many. Who doesn't know what Spotify is? Well, basically it's a music streaming service and they use web services a lot. So Jay, gonna talk about this, or we'll decide if just enough of the theory. It's a bit of a fun example. So essentially Spotify is a client application that connects to various services. And in those services, this is just a diagram of some of the infrastructure and the architecture, sorry, that Spotify have. And it uses a client application on the user's computer. We'll talk about web for now. Which connects to a metadata service which provides information on artists, songs, and albums. It also has a user service which is used for personalization for the user. And then there's also another service which is their playlist service. And that playlist service early on in Spotify's, I guess, their establishment, it was actually a peer-to-peer network. And what would happen is that you'd be accessing music from the client application and it would go out, if it didn't find it on your local cache, they do rely heavily on your local cache of your application. And if they didn't find it there, it would then go off into a peer-to-peer network and it would try to stream that music from other users who had already previously downloaded those files. If it didn't find it there, it would then go to Spotify's servers. And whilst they were in their lean days, bootstrapping the business, was the way they could cut quite a few costs related to their servers. So Spotify, that architecture is the prime example of where web development is tending to move to. You have a client application which could connect to a front-end framework and then, or it could be a mobile application and it's completely decoupled from the back-end services. So why would this be so powerful? Does anyone sort of have a good answer for why you would do that sort of thing? Definitely mobile apps. So does your website? Yep, that's a good one. Any other suggestions? Right, your laptop. Yeah, exactly. And that points to this here.  And so when you create an application that is good enough to make other people want to connect to your application and use that for their own services and to build their own websites that are built using your data, that's when you've made something special. And this is the Spotify web API and I'm just going to jump out of here and go to the live thing because we have internet, it's a wonderful thing. So this is just at developer.spotify.com and the main purpose is just to demonstrate a pretty good API. Spotify do have a great API and without going through each endpoint, you can see that they've got get methods on things, put, delete. We'll get into those details a bit later but it's really well documented. So I might just sort of jump out of here. If you go in, it's got a heap of information and it's basically when you're building your services with Drupal 8, this is kind of the level that you would want to achieve if you want other people to connect to your services as well. And it's just an explanation of you've got the endpoints, request parameters, response formats and then any error handling, expected data that you receive upon making a request. And oh, comment section because a comment section on your API is excellent. So with a large increasing number of developers looking to build their websites why would you want to expose your own API? And why would you want to take on this approach? And the answer is just back here. I thought I saw that one. Sorry, technical difficulties. I swear I do web, I swear. There we go. Okay, and this is why. Leverage, leverage. So you want to be able to leverage what you do. And that means that you'd want to connect to other people's services and just keep going, just in case you missed it. Now, you may want to connect to the Spotify API because you might have a music site and you want to quickly have access to a massive library of information, artists, albums, songs. And to do that all yourself in the early stages is quite difficult and quite time consuming. So you want to be able to connect to as many different services as possible to try to get that through that lean stage. If that's your aim, to build lean and to quickly, and to scale as well to make the most of other people's services. All right, so we just saw one example of how you can leverage the services for Spotify but there are tons of other services and alternatives to Spotify as well. So disclaimer is not an advertisement for Spotify. So don't, although you can check it out there. But in terms of Drupal and websites in general, the services actually give you basic examples of where you can use the services. By passing, for example, the theming layer. One of the good example it can be done, for example, if you use Moodle before, a lot of people complain it's a pain actually to create, Moodle is a learning management system and in there you create your course, you create your week by week curriculum, you create your lectures inside your weeks. And a lot of people saying the actual process is a pain, big, big pain. So for example, if you would have actually leveraged the services, you would be able to structure, structure your form differently and actually, for example, quickly submit multiple items. So for example, if you have your lecture, you have your week, you have your course, you can actually do it, for example, one page using services and it will create at the might be 10 or 15 different lectures and populated just using my form. This is one good example where you can actually use services to override the existing functionality or existing form and just expand it. So you can use it for web applications. So for example, if your business logic is more complex as well, the Moodle is a good example of actually creating some more complex form and using web services to create multiple items on the back end, making user actually to work with what they like rather than sending user to the same page 15 times to create the same lecture or something like that. So this simplification is one of the things. Another thing is mobile application. It became very, very big. So a lot of things you use in your daily life actually relate to mobile application and a lot of them, I don't know, I use RunKeeper, Facebook, Twitter, all that stuff uses services to actually update the data, create the data, delete the data. And that's why we're gonna quickly look at web services API because go into another example and to Drupal. So basically to actually have a web service, you need to have a syntax. Syntax to understand how language works. You need to have methods, understandable methods and know what they do. So it's basically, let's say it's an action. You need to have some sort of a URI. So basically somewhere to connect. So like an endpoint. This one doesn't work. It's super complicated. All right, enough. I can be loud. Yeah, so you can actually need to have some endpoints to connect. So if you didn't understand much of the previous slides with Spotify where you can see a bunch of URLs, there you go. So here's your method called get. So you're getting endpoint. You got a particular identifier to actually what are you getting? And yeah, that's basically the description of what it does. So, and then you get an extra information. So for example, why do we need an extra information?  If we're talking in Drupal terms, if you wanna create a page, you need to send title. You need to say the body tag and you need to send if the page is published and unpublished, particular date and so on and so forth. So actually you need to send some parameters there. And data types, what are you actually sending? We were talking about JSON, we were talking about XML. Maybe you wanna set EDI. No recommend it. He doesn't. And the message form has already been talking about them. So two most popular ones are JSON and XML. Soap is still heavily used. So don't get your hopes high. There is some enterprise to go to come up to this. And I got this soap. I want you to fix. And there are other formats as well. I'm not gonna cover them. They're not in the cool. And we have a request action. And you've seen, how many request actions are there? Five. One came in late, but it actually get. It's post, it's put, it's patch, and it's delete. Drupal actually have, Drupal eight have full. And we go to get. So get requests are used obviously to retrieve data from the resource. And typically with get requests, you use a parameter in the URL to retrieve the data that you need. And because that request is done through the URL, is a query parameter, it has a limit of 2,048 characters. If you're using a get request with more than 2,048 characters, you might be in trouble. Next one is post. Now post sends new data in its complete form to the resource. So it's basically used to create a new entry in the database table. And the query strings are actually sent in the HTTP message body, either as XML or JSON as well as we've already discussed.  And that uses the URL for the query parameters as well to identify which record in the database you wish to delete. So we also have put and patch. So they all basically decide to modify the content. The main difference between two of them is put is a completely replacement. So if you have a page, you do input on this page, it basically replaces everything. Whereas patch, it replaces, yeah, so it sends an update's request, creates a snapshot and copies the resource before it's updated. So it's basically have some mechanism to actually pick it all up. Whereas patch, what it does, you can actually, it's a partial update. So you wanna update the title, you use patch. And that's what Drupal is using instead of put. We gonna talk a bit more about authentication, so how you can actually protect yourself with, so someone won't go onto your website using web services and actually deletes your page. And there is one talking, on top of authentication, so top of your credential you use, you're also using talking for patch, delete, put, and I think for post as well, but not forget. So authentication, it's basically your credentials. Basic Drupal authentication is cookie. So when you put your login and password stored as a cookie token, and then you can access it that actually proves Drupal, you are authenticated. There's very popular OAuth, which is used by Facebook, which is used by Twitter, which is very, very popular standard at the moment. And just to get to another example, which is completely different, this is example more for developers, but it actually will show you how services can be leveraged by developers. So has anyone ever heard of Dream Factory? We have, we've got one person. All right, cool, so this might be pretty interesting. So basically Dream Factory is a way to connect multiple APIs into a single service. So I'll just go out here and it's open source and it's built with PHP and Apache and it uses MySQL as a default database. And it automatically takes services that you attach to it and generates RESTful endpoints. And what I'll do is I'll jump into an example of this. So this is the Dream Factory interface and I'm just gonna skip over most of the stuff just to get to the important parts. But a quick overview is that you attach an application and then from that application, you attach multiple services. And in this example here, I've attached a MongoDB here. Which is a database, so it's basically a source of data. Sorry for anyone who's unfamiliar with MongoDB. And I've also attached the Rotten Tomatoes API, which is an external service. And what that does is, actually I'll just give you a quick example. Just stop here. What that does is it generates the APIs in a single service that you can use. So you use familiar endpoints for all services. And you can see here that we've got BBV. And if I just expand that, that will list out all the endpoints that you can use to interact with your database that you attach. Or it can use the default MySQL database. So you've got those get methods, post methods, port, patch, delete. And if we move down to the movies with Rotten Tomatoes, you'll see here that there's a get request. And this is just directly talking to Rotten Tomatoes and I can type in something here. I don't know what, that's not gonna come up with anything. Who's got an example of a movie named? Interstellar. Sorry, Interstellar. We'll go with Interstellar. Counting active. Oh, excuse me, yesterday. Authentication. Yeah, yeah. So there's a good example of what happens when you don't use authentication. Woo! All right, so I'm gonna actually go back up to the connection here that I've got with MongoDB because I know this one should work. And just to get request, I'm just gonna search for the content table in this database and you get the results there in the response body. So what I really wanna talk about with this is that it's a quick way to have multiple services connected and to develop using just that single URL structure. And it will save a lot of time instead of sort of having to format many different ways of retrieving data from multiple services. You can actually aggregate them all into this one service. And another cool thing about this is this interface here is Swagger. So Swagger here is like a documentation UI where you plug in your services and I'll just give you an example of what you need to add to this service. You simply add a JSON file for Swagger and enter in some details and then it will build that API documentation for you. So you'll be able to pass on your API to somebody else and have documentation created very quickly. So reverse scroll, it gets me every time. So that there is an example and it's just basic JSON and you fill out some details and from those details, you can then build out a UI via API docs. Can be very helpful when we have lots of services exposed in Drupal to actually leverage another open source system to give the details of those services exposed in a nice manner. Is that a standard or is that something new? So, no I was wondering if this was something Dream Factory came up with or if it was like more of an industry standard? No, so that's Swagger is found at Swagger.io and we'll have the link in references section for the presentation. And currently there is a Drupal 7 module, a Drupal 7 sandbox module that has tried to integrate this. They haven't touched Drupal 8 but I think it's gonna be really powerful for Drupal 8 with everybody working predominantly with services and wanting to expose those services to be used either across your own applications or for anyone to use and having that documentation built. So I think it's great. You get, I'll just quickly jump back in. You get access, which is built on the fly to information about the API endpoint. You get an example schema of the response class. You've got response messages that can be documented and in the response itself, as I showed you before you get the response body and you know exactly what sort of data you're working with and somebody who doesn't know anything about your application can go on, have a look at this documentation and get a good idea as to what to expect and how to work with your API. And finally, we're here to actually talk about Drupal so it's time. So anyone heard term headless Drupal before? Yep, so headless Drupal refers to services and it means they basically chop off Drupal's head and not using the theme layer which is there are lots of talks about it what's best way. So it's just an alternative way to actually use the Drupal by using it as the data storage, exposing the services and actually leveraging the services that we were talking about. It was one of the main core initiatives. There's a lot of documentation about it and you can go on Flixer Archive and see how big development was. Actually resulted in a few turns but basically it went through a few stages. They basically when the initiative was announced they say we need to build the context which is basically exposes the data first and we need to build the plugins which basically the way for developers to expose the services and then we actually need to expose the service. So that's what the initiative went through and now we have services in the backend and layouts as well of course to actually how they're gonna look. So that services in core but also services are in views. We're gonna go through, we got about seven, eight minutes. We're gonna go through the examples of it now. So there are also additional modules that I'm gonna cover that basically just gives you a better understanding of what services are and how to use them. Actually gives you a visual stuff rather than going and looking at it in the backend. And also there's some services development postponed to 8.1 which we basically cover just a touch base in the end. Okay, so four main modules that come with Drupal 8 that it's whole HAL, there's HTTP basic authentication, there is the restful web services and there is serialization. So we'll start with the restful web services. So again, it actually exposes the services for REST APIs that creates, makes Drupal one of those applications or so before. So let's all go and build our next Spotify. We can expose other resources and it's also, it depends on the serialization module which is actually converts data from the format of your choice to Drupal language in the back. So then there is HAL which states for hypertext application language. It's extends serialization module and it's a primary format for Drupal to understand the service you signed in in. And again, it can be encode both in JSON and XML that we were talking about. And this is showed some developers info so it basically enables couple of keywords for Drupal. Then there is a syndication module which basically provides service based on cookie. So if you log in into your Drupal, you can go and query your stuff. But it is recommended if you're making a production site to configure SSL which is secure protocol to communicate over. And there is all awesome module already available for Drupal 8. So you can actually go and install some modules. And the authentication, this is a link for authentication which I'm gonna cover in a second. We're gonna use Postman REST Cloud and we're gonna communicate with our Drupal site. Let's do that. So we have our Drupal 8 website. We have some content, something like we created three pages. The content I've actually called page element but we have node one, two, and three. So in order to actually get JSON from the view, we're gonna use URL. So it's node three. Go back to our Drupal. This is our node three called mission. What's our mission? Alternative accessible. So this is the data we actually currently have in Drupal. So we'll try to send the request one more thing. We actually say, as you can see, we're sending the request of the same URL to node slash three as the actual node is. And if we send the URL, it's gonna fetch JSON. The reason it fetches JSON instead of HTML, it's this line. You're actually sending the header that accepts application JSON. If we delete that and send the same request, we're gonna get our HTML page. Basically, exactly what you see in Brawler. So by just changing, you basically can request the same URL, but depending on what you want to request, Drupal would actually feed you stuff differently. And I guess this is the main thing for the services. So same thing if you wanna delete a node. Again, this has come, now we need the actual authentication unless you allow everyone to delete stuff. And first, if again, I'm sending here, we can select delete. Yeah, first I'll show that it actually says 404 node found. So we know there is a node number three. So we'll go here, it's actually mission. So update that here and say I wanna update node number three. And it's actually says 403 forbidden. So that's where the permissions comes in. So first we need to allow the user to delete nodes. So let's, at the moment, let's do what you will never do in any environment is allow anyone to delete the node. So we'll say anonymous user can call delete on the resource. So it's all in permissions in Drupal A. So we save that, we'll try to delete it again. So it's 403 forbidden. Does anyone know why? Basically to prevent people from actually deleting stuff, you also need a token. So if you work with any API like Twitter API and stuff, but from your credentials, you'll also get an application token that Twitter confer. So it's like double confirmation that you actually are the person who wants to delete all update stuff. Token in Drupal 8 sits in a URL called the rest session token. And you have to type it together. So it provides me with API token. So I'm gonna go here and post. And it's actually called XCSRF token, which I posted in there. Oh, let's try to do it again. So it's not 3 cent. And it says 204 no content, which means it was successfully deleted. So I guess sacrifice to the guys of the demo was good enough. So Drupal also provides rest in views. So for example, if you have a bunch of pages and you wanna provide a summary for those pages, you can actually just give them straight in one request. So for example, I had three pages. If I wanna receive them in one request, I can send the rest request to the views. It's a visual query builder. So it's basically aggregates data from Drupal and exports list of data. So you can select JSON and XML for those people who know views you go and add new view. And then as before as Drupal 7, you have page settings, you have block settings and you also have rest export, which is basically gonna give you the same details. And the way you select the format, you actually go into a view settings and you select JSON or XML. Rest UI, it's very handy module. It actually provides you with the visual data. So basically it says, okay, what do you wanna to enable? Do you wanna, for your content, do you wanna get, pause, delete and patch? It also provides those permissions we saw before. And as you can see, there is a resource name and pass, which is at the moment, it looks like that, but we can also integrate it with... Swagger. Swagger and actually expose the APIs to external users. So you can actually select an authentication depending on, so you can select authentication cookie, simple authentication or auth if you install the module. So that's, yeah. And there is couple of more modules. If you're interested in authentication, there are references to couple of modules. One more node on Drupal 8 is actually it's built on symphony, which is a framework for PHP. It has a thing called Sylex, which is now built in in Drupal 8. And it's basically just give you easy way to expose eight end points for the services as well. It's a very popular framework for people who actually work with symphony. And here's a bit more details about that. All right, now I'll be quick because we're running out of time. So has anyone tried to connect to an external domain using JavaScript from their website and come across this error? So, yeah, this one's... This one, the first time you come across this year, look, you think to yourself what the hell's going on. Basically, it is because of cross origin access. And what it does is it was implemented on the browsers to prevent communication between two sites with different domains. And the reason it was put in place was to help prevent cross-site scripting. Now, I was gonna talk about that, but look up cross-site scripting if you're unaware. I believe everyone would have some ideas to what that is. And what's come about from that is an initiative by W3C to standardize cause, which is cross-origin resource sharing. And you can go to w3.org for a dry read of cause. There's also another website called enable-cause. We're gonna have the references, the links in our references section. But basically with Drupal services, you may find yourself wanting to go with a headless approach, but at the moment, Drupal doesn't support that. And what that means is ordinarily, you would have an access control allow origin header in the API on the site that contains the APIs to request the endpoints from. And you just have to point that to your domain that you want to use to query that. And with it not being in Drupal 8, there is good news. It's actually coming for 8.1. So there is a thread, which we'll put a link to in the references as well, where there is a current patch in this same thread that you can use now. If you wanna be able to have a headless front end, sorry, a headless front end connecting to your Drupal site that may be on a different domain. And that can be useful for many different reasons. But it is coming and just check out that thread for the patch to work with in the meantime. So we are doing birds of feather tomorrow at 2.30. So we're gonna display a bit more hands-on developers approach with services of with Drupal 8 and Drupal 7 and talk about all sorts of trouble with services and solutions as well. So if you've got anything to talk to, if you wanna ask something or just here and just come to us, we're in room F. And thanks guys, do you have any questions? It has a services module. Is Drupal 8 exactly the same or is it different? I mean, apart from that, it's a core. Yep. But is there any difference between a Drupal 7 services module and Drupal 8? Yep, it was completely written for Drupal 8. And I was trying to find information, the Silux. I'm not sure how far Silux is integrated in Drupal 8 initiative. Larry Page at Crel. Crel, he's a lead on that. So I think if you wanna get more in-depth, you can contact him and he's quite a talkative guy. What does API like provide more than that? I'm not sure how deep goes Drupal 7, but at the moment we found two problems. So first problem, you cannot expose blocks. And second problem, you cannot expose menu links. You can have one menu link if you know the menu link AD. So one of the things, the rest of it is available. So you can expose views, you can expose all the content, expose particular content type and modify pretty much everything apart from that. No, you can't do that because views don't support menus yet. That's another problem we found. So there's a lot of stuff that actually postponed into 8.1, but one of the things we're gonna show off tomorrow is I created the plugin to expose the links in the menu.  So basically if you wanna expose views and wanna expose views and pages, you can put them together in one menu, then we can read list menu. So it's not available out of the box, but I think it's coming because both blocks and menus are entities. I guess it just wasn't there in the time of making this presentation. You said that in truthfully it only has four to five methods. Yes. And it's missing, what's that like? I think put is missing. Yeah. If you want to insert new content, you just use patch, is that right? New content will be with post and then to update content, you'll be using patch. Anyone else? Thanks for coming guys. Yeah, thanks very much. Hope to see you tomorrow. Thank you.