{"API Evangelist"}

I Just Cannot Get Behind API Patents, Especially When They Apply To HTTP And Hypermedia

I got an email in my inbox, about a new API modeling language from Elastic Path earlier today. The product is called Helix, and is sold as being "the first enterprise-class API modeling language designed specifically for REST Level 3".  

The Elastic Path team is where I first learned about the concept of hypermedia, I believe back in 2011--honestly, I had heard the concept before, but never fully grasped what it was, and the potential until 2011 (I know I am slow). However it has been an awareness that has grown rapidly, the more I learn about hypermedia, study how people are practicing hypermedia, and even dabble in it myself with my curation, and building block APIs.

Elastic Path is an expert in the area of hypermedia, so it makes sense they would step up with some hypermedia focused API tooling, and even a modeling language. No surprises here, but where I was a little surprised, was when I read the "Why Helix":

Elastic Path built Helix because existing API modeling languages, such as RAML, Swagger, and API Blueprint, while good for describing standard APIs, are not well suited to designing hypermedia APIs. Elastic Path Cortex, our patented API technology, utilizes Helix definitions and a Helix-compatible implementation, allowing our partners and customers to extend existing APIs and quickly create new ones.

After reading, I wanted to explore the portion of their description that states, "Elastic Path Cortex, our patented API technology, utilizes Helix definitions and a Helix-compatible implementation, allowing our partners and customers to extend existing APIs and quickly create new ones.", but specifically the "patented API technology". Something a quick Google Patent search discovers as defined five separate patents held by Elastic Path

Linking functionality for encoding application state in linked resources in a stateless microkernel web server architecture
Publication # US9143385 B2
A method of serving a resource to a client via a computer network is provided. The method may include at an HTTP server system having a stateless microkernel architecture, the server system including one or more link resource servers, receiving an HTTP request for a resource from an HTTP client via a computer network, the request being to perform a resource operation, the resource operation being to retrieve the resource and send the resource to the requesting client, wherein the resource is a data object. The method may further include determining if the resource operation is authorized based on the request. If the resource operation is authorized, the method may include sending the resource operation to an object server associated with the resource identified by the request, in response receiving a data object from the object server, providing, via a linking engine, the data object to each link resource server of the one or more link resource servers, in response receiving one or more links from each of the one or more link resource servers, embedding the links in the data object, and sending the data object to the requesting client via the computer network.

Follow location handler and selector functionality in a stateless microkernel web server architecture
Publication # US8959591 B2
A method of serving a resource to a client via a computer network is provided. The method may include providing a follow location handler logically positioned on a WAN side of an HTTP server. At the follow location handler, the method may include receiving a POST request from the client, and forwarding the POST request to the HTTP server. At the HTTP server, the method may include receiving the POST request, creating a modified data object based upon the form data, generating a link to the modified data object, and returning the link. At the follow location handler, the method may include intercepting the link to the modified data object from the server, sending a GET request to the server to retrieve the modified data object, and, in response, receiving the modified data object. The method may further include forwarding the modified data object to the client.

Stop condition functionality in a stateless microkernel web server architecture
Publication # US20130179498 A1
A method of serving a resource from an HTTP server system having a stateless microkernel architecture and one or more link resource servers is provided. The method may include generating a data object in response to an HTTP request, sending the data object to each of the link resource servers, and at each link resource server receiving the data object from the handler and examining the data object for pre-determined information to perform a linking operation. The method may further include if the data object includes the pre-determined information, performing the linking operation by returning one or more links to the handler linking to related information provided by the link resource server. The method may further include if the data object does not include the pre-determined information, not performing the linking operation and instead returning one or more stop condition links indicating that the pre-determined information is not included. 

Stateless microkernel web server architecture with self discoverable objects
Publication # US20130179545 A1
A method is provided for exchanging a self discoverable data object between a client executed on a client computing device and a server with a stateless REST-compliant software architecture, which is configured to reply to HTTP requests from a browser engine of the client and to messages from a runtime executable program executed by a runtime executable program interpreter of the client. The method may include receiving an HTTP response from the server, the response including the data object, the data object including a self entity including a URI and a content type of the data object, passing the data object to the runtime executable program at the runtime executable program interpreter for processing. The runtime executable program may communicate with the server using the URI and content type of the data object. Cache controls and an HREF may also be contained in the self entity. - https://www.google.com/patents/US20130179545?dq=inassignee:%22Elastic+Path+Software,+Inc.%22&hl=en&sa=X&ved=0ahUKEwiRnsHvlaXKAhVC9GMKHbyMAuIQ6AEIOzAE

Encoding application state in linked resources in a stateless microkernel web server architecture
Publication # WO2013102272 A1
A method of serving a resource to a client via a network is provided. The method may include at an HTTP server system having a stateless microkernel architecture with one or more link resource servers, receiving an HTTP request from an HTTP client to perform a resource operation to retrieve a resource data object. If the resource operation is authorized, the method may include sending the resource operation to an object server associated with the resource identified by the request, and in response receiving a data object from the object server; providing, via a linking engine, the data object to each link resource server of the one or more link resource servers; and in response receiving one or more links from each of the one or more link resource servers, embedding the links in the data object, and sending the data object to the requesting client via the computer network.

Hmmmmmm.....

I know you all think I'm some hippie dippie API dude, who doesn't get all this VC driven, business shit you are all calling startups, and innovation, and you are probably right. However, I'd argue that many of all you really do not get this Internet, or API thing either. This is a hard one for me, because I've worked with Elastic Path since way back in API Evangelist history, and I personally know and love their team. So its hard for me to call bullshit on this, but I have to. 

I'm not all the way through the detail of the patents, but in my opinion, they should never have been approved. They go against everything that is the Internet, and why APIs work. The only thing I see unique in the patent titles, abstracts, and art, is the term "microkernel". Not sure exactly what that is, but the rest of it sounds like what we are all already doing with APIs to me--correct me if I am wrong?

Luckily patents are coming back onto my radar, thanks to my lovely partner in crime doing the research for her piece, Ed-Tech Patents: Prior Art and Learning Theories. Her work, and this release from Elastic Path is encouraging me to spend some fresh time going through my patent research, and make sure that I am paying attention to this type of stuff in real-time. I started my dive last January, making it a perfect time to refresh my research in the area.

I swear, with the Oracle v Google, last years Swagger bullshittery, and now this, y'all are going to turn API into SOA, and then everyone is gonna be whining at me that I promised this API thing would work!! Luckily someone will come along with the next thing to sell you fuckers, make money, and y'all can fuck that up too. #IFuckingQuit!