Last week, my colleague Rajiv walked you through an overview of how our Mobility Services API now supports REST based APIs. As a developer for the Mobility Services Engine (MSE) team, I am very excited about this update because it means that it will be easier for developers to create apps using the MS-API, which hopefully means that more and more organizations will be able to take advantage of the location-based services and functionalities of the MSE. I’m going use this blog to walk you through some of the more technical aspects of the change.
The REST API is now widely used in the field of API based web applications. The REST stands for REpresentational State Transfer. It is an architecture that is based on set of six rules, and APIs that support REST follow all those rules, making them RESTful.
Compared to SOAP, REST has better performance, scalability, simplicity, modifiability, visibility, portability, and reliability. For secured REST API transactions, HTTPS is recommended.
RESTful Mobility Services API
7.5 applications, including features from the Connected Mobile Experiences (CMX) solution such as Browser Engage and CMX Analytics, are now supporting REST APIs in addition to the existing SOAP APIs previous releases (backward compatibility).
CMX utilizes the basic authentication scheme to authenticate each REST API request. It utilizes the Authorization header in the HTTP packet. The Authorization header is composed as follows:
- Username and password are combined into a string “username:password”.
- The resulting string literal is then encoded using Base64.
- The authorization method, a space and the string “Basic” is then put before the encoded string.
The API credentials can be accessed from Prime Infrastructure (PI), which manages CMX (page is located under Mobility Services > Specific MSE > System > Users).
As Rajiv mentioned last week, the Mobility Services REST APIs can be grouped in the following way:
- MAP APIs
- Real time location APIs
- Location history APIs
- Notification APIs
Let’s break them down with use cases to get a better picture of when you’d use which. Read More »
Tags: API, App, app developer, application, application developer, application development, code, Development, engineer, location, location based services, map, mobility, mobility services, mobility services engine, MS API, mse, network, REST, SOAP/XML, technical, technology, wifi, wireless
As a product manager, I am happy and excited to tell you that Cisco Mobility Services Engine (MSE) now supports REST based APIs. Why am I happy and excited you ask? MSE’s REST based APIs allow web app developers to rapidly develop location aware apps with ease. Let me walk you through this new feature at a high level, and my colleague will take you through a closer look feature blog next week.
Mobility Services Engine and API support
For readers who are not familiar with the Cisco Mobility Service Engine and the APIs, here’s the gist:
- Cisco Mobility Services Engine (MSE) works in conjunction with Cisco Wireless LAN Controller (WLC) and Cisco Aironet Access Points (APs) and computes real time location for all Wi-Fi end-points using RSSI based triangulation algorithms.
- MSE stores real time and historical location of Wi-Fi clients in its database making it a gold mine of data for indoor location. (Remember that GPS technology is not effective for indoor location)
- This rich store of indoor location data is now available to app developers to query through a REST based API over a secure HTTPS connection.
What can I do with MSE REST APIs?
MSE REST APIs allow web developers to query MSE location database using the HTTP(S) GET method. HTTP response payload can be received in XML or JSON format. Here is a list of resources that are accessible over the REST API. Read More »
Tags: API, Cisco, cmx, connected mobile experiences, HTTP(S) GET, location, location based services, map, mobility services, mobility services engine, mse, real time location, REST, rtls, web developer, XML
Within the coming decade, Internet Protocol version 6 (IPv6) will be key to enabling 50 billion connections among people, processes, data, and things in the Internet of Everything (IoE). But how we get there from here is not a simple matter.
I’m very pleased to invite Mark Townsley, Cisco Fellow and recognized industry expert on IP, to discuss this important transition in the second of our three-part blog series on IPv6. The first blog in Mark’s series was “Demystifying IPv6”.
Three years ago, I organized a conference in Paris where I thought it would be fascinating to bring together the original designers of IPv6 alongside the engineers who were finally deploying it at scale more than a decade later. During this discussion, Steve Deering, one of the “fathers” of IPv6 in the 1990s, was asked one of the most common questions about IPv6: Why wasn’t it designed for backward compatibility with IPv4? After all, wouldn’t it be easier to make the transition if the two versions could transparently coexist? Steve answered that the problem is not that IPv6 wasn’t designed to be backward-compatible—the real problem is that IPv4 wasn’t designed to be forward-compatible.
Steve was making the point that IPv4 was designed with a fixed address space. Given the number of computers connected to the Arpanet throughout the 1970s, this fixed-length address field seemed to be sufficient—at least for that version of IP. IP had been replaced before, and it seemed perfectly reasonable at the time that it might be replaced again. Read More »
Tags: 6rd, Cisco, Internet of Everything, internet of things, internet protocol, IoE, IoT, ip, ipv4, IPv6, IPv6 rapid deployment, map, mapping of address and port
By Steve Simlo, IPv6 Product Manager, Cisco Network Operating Systems Technology Group
As IPv6 gains more and more ground within the Internet we are starting to see recognition amongst the wider community that technologies such as Carrier Grade NAT (CGNAT) have some significant drawbacks from a service and scalability standpoint. Some of the issues were recently highlighted by a major carrier which actually issued a public “opt out” option to their customers if needed.
However, there are some applications such as online gaming, VPN access, FTP service, surveillance cameras, etc., that may not work when broadband service is provided via a CGN. For our customers utilizing these types of applications, we provide the ability to “opt out” of CGN Read More »
Tags: cgv6, Cisco, Internet of Everything, internet of things, IoT, IPv6, map, Service Provider, Steve Simlo, World IPv6 Congress
We first talked about the Mapping of Address and Port (MAP) method to handle IPv4 exhaust and the transition to IPv6 last week. MAP is based on two IETF drafts currently in the process of standardization in draft-ietf-softwire-map (MAP-E) and draft-ietf-softwire-map-t (MAP-T). The real advantage with MAP is that it’s stateless and doesn’t require additional hardware as traffic grows. Read More »
Tags: cgv6, Cisco, DSLite, IPv6, map, MAP-E, MAP-T, Mark Townsley, Service Provider, stateful, stateless