- [Instructor] Let's look into the Rest API. As you can tell we use the http verb POST to create an index and then we used PUT to update the index. In this case, you could use either of the two. Then we have delete which is the http delete verb which is required to delete that particular index. And then we use GET to just list what we have so we can either get one record or we can actually do the entire search and get a list of records.
And of course, it will return the HTTP status codes that are very standard, and we will also have to use our API keys. We can use the query API key to read anything and then we would need the master keys, or the management API keys to be able to make any changes especially update, delete, and create. So, what's an index? Index is an entity of concern. So for example you have an accounts JSON file and it has a list of accounts for a person.
It's got his first name, last name, email, and then details about the account, address, information, lot of other things. That entity account could actually be an index. We want to index it at the level of account entity and then we want to take the properties and convert them over as fields that the index is composed of. An index in Azure Search has a schema. It has a well defined schema. It also has a CORS option which takes care of cross origin requests especially since you are building an API you want to make sure that that API is only called from the domains or sub-domains you trust.
And that could be defined in the CORS policy. For example, once you launch for API, you want to say that example.com can only call my API. And if I get any other requests from anything outside example.com, I don't want that to happen. Maybe you can define another request saying well forgot requests I don't care, anyone cane make a call to me as long as it's a valid http call, let's allow it. But otherwise, for everything else, only allow admin.example.com to call me.
Now those are your CORS options and it has really nothing to do with Azure Search in particular but it's a good practice for any API to have. Now this only says that Azure Search allows you that option. And then you can add a lot of search options which we'll look into in few minutes. An index could be created in multiple ways. You can either do it through the portal or you could initialize an index through your application. And most of the times you're going to end using a web worker to create enticies at the same time, update them and add documents to them.
Another way to look an index if you're coming from an RDBMS background is think of index as a table. And the fields inside an index could be the columns of that table, and when you start adding documents with the values those are the rows. As we discussed, creating the index happens with HTTP POST. And, we will use a content-type which are the box application/json is supported. And then we will have a body. Here's an example of the search URL using cazton.
That is just the name of your search service in Azure. Any search service you take, it's going to be searchservice.search.windows.net and then you'll have /indexes, and then you will have the name of the index. So if you had an accounts index, you'll add the name right there and then Azure Search forces you to use an API version. And that's because if you're using a previous version of Azure Search they want it to working for you unless you decide to upgrade to the next version.
So that version has to be part of that URL. Now an index can have a lot of things. First of all it can have the name of the index and you can set the name of the field here. And then we have the type. Searchable, now this particular property will mark the field as a full text searchable field. Do you remember the discussions about the tokens? Anything marked searchable will be split into tokens.
Splitting it into tokens actually enables full text search for those terms. So if I have something like developers are cool, and I want to make it searchable, behind the scenes Azure Search will break it down into three words. That will be developers comma are comma cool. So, if I search for are, that particular document will still show up. And if I search for cool it'll still show up. Or if I search for are cool it'll still show up.
Now, the only downside with this is that it's an expensive operation because when we tokenize something we are bloating our index. Because now you have multiple tokens for the same exact field and that means it's going to consume extra space in the index. So we should only make something searchable if we know that we will end up using some kind of full text search on it. Filterable is very similar to searchable except it does not consume extra space.
However, if you had a field which is of type string, or even a collection of type string, you will have to give the exact value in case it's filterable. So if I have the value called cazton, then I'll have to spell out cazton. But if I had a value called developers are cool, I will have to and write developers are cool. And if I search for developers are, no result is going to come back if the search was an equals search.
I can have a filter that says x equals developers and developers are cool will not show up because it's filterable and it's not full text searchable. So, that's one of the major differences. Sortable, if you remember our discussion about boosting by default the system will sort the results by the score. But sometimes, you may want to sort by other fields in the document. So for that you will use the sortable option.
Facetable. Now facets are really cool and you've used them many times even though you may not know what the technical term is. So if you go to any website and you try to buy let's say a laptop, and then you go inside the laptop and you want to buy a laptop which has different price ranges. You can select from anything less than $500, anything between $500 to $800, $800 to $1,000, and then $1,000 to maybe $10,000. Well and those are four different facets.
Those are four different categories that you would like to search from. At the same time, once you picked that particular facet which was the price facet, you could now also pick a memory facet. And the memory facet could be eight gigabytes, 16 gigabytes, or 32 gigabytes of RAM. Those are two different facets. And faceting is very easy when it's a search engine like Azure Search. But if you are using an RDBMS, creating a facet is definitely expensive and it takes a lot of time to code it.
We'll show you an example later on how to create facets by just writing few lines of code. The next one is key which is exactly one field inside a document. So, you cannot ever have a document with more than two fields that are keys since it's like a primary key. These keys can only be used to look up the documents datically. And it has to be of the type edm.string. Retrievable means if you mark this true that particular field can be retrieved in a search result.
Now there are times when you want to use something for a filtering, sorting, or even scoring mechanism. But you don't want the field to be visible to the end user. At that time, you will mark this as false. Next one is an analyzer and Azure Search supports analyzers. Couple of examples are search analyzer that will set the name of the analyzer used at the search time for that particular field. Now this can only be used by the way with searchable fields.
And the index analyzer will set the name of the analyzer that's going to be used at the index time. So, that's the difference. Now, it could be any kind of analyzer which is either supported by Azure Search or something that you might end up creating. But those are the only two places you're going to end up adding an analyzer.
- Querying and indexing
- Creating a search service
- Using APIs during searching
- Importing JSON data
- Handling synonyms
- Working with suggestors and facets