A few quick definitions

Regarding the last post I put up (here if you’re reading this on annathepiper.org, and here if you’re reading it on Dreamwidth), I thought I’d do another quick post with some definitions of terms I’m throwing around, for those of you who aren’t in the tech industry and might not know what I’m talking about:

API: An API is basically a known set of ways that a program, operating system, or in this case a website makes available for others to hook into and use. For example, Apple has an API for developers to use if they want to create apps for iOS. What I’m doing is playing with the REST API that WordPress makes available as part of the WordPress code.

Service: A service is a thing that sits underneath a website and does a lot of under-the-hood things for it. I described this on Facebook as being part of a website’s engine. It’s not something a user would see just interacting with a site in their browser, but it’s an important thing nonetheless, and it’s there to help the website do its job.

REST API: REST is specifically one type of format an API might take for access to a web service. This Wikipedia page has more if you want to read up on it. But for purposes of this post, I’ll simply say that the REST API endpoints I’ve worked with to date, both in the context of a job and on my personal coding projects, are endpoints that return JSON payloads that I can test against.

JSON: JSON is a file format with a specific syntax and structure. It gets used a lot in web services as it’s reasonably easy to parse, as well as hand back and forth through various steps of a web site’s operation. So when I see a JSON payload come back off a web service endpoint, I can use my test automation to analyze that payload and look for interesting things in it. For example, an HTTP response code, like a 404. Or an error message or error code. OR, if the test is specifically looking for a successful response, I might be looking for an expected title or body of content. Since I know I’m dealing with JSON, I can set up my code to drill down into the payload and look for these specific things.

Endpoint: An endpoint is basically one of several routes you can use to do things with a service. It’s more or less a URL that you can use to make the service report back on various things.

So with all of those identified, does it make more sense now if I say that my demo tests are hitting the documented WordPress REST API endpoints, looking at the JSON I can get back from those endpoints, and analyzing them for various things? Let me know! And let me know if you have any questions. :)