Hypermedia sounds great in theory, but theory only goes so far. Where hypermedia really shines, or completely fails, is in implementation. Unfortunately, as hypermedia is still a relatively new aspect of web based APIs, there isn’t one specified way of doing things. In fact, you’ll find that even some of the most popular APIs operate completely differently from each other.
This is part four, sub-series 1, of the API design best practices series.
One of the challenges to implementing and correctly using hypermedia in your REST API is first understanding what hypermedia is, and what it means to use hypermedia as the engine of application state (HATEOAS).
This is part three of the API design best practices series.
Once you have an understanding of what your API needs to be able to do in order to meet your developer’s requirements, it’s important to ensure that it remains as flexible and extendable as possible. Taking advantage of best practices not only means that your API will be familiar to developers, but also ensure that it remains fluid enough to extend and build on top of it in the future. Here are this week’s best practices to help keep your API agile:
This is part one of the API design best practices series.
Perhaps the foundation of the foundation, understanding why you are building an API is a crucial step towards understanding what data/ methods your API should make accessible and how your users will utilize it. Unfortunately, API is a buzzword right now, and many companies are rushing to build APIs with the idea that “we’re going to make our data accessible and our users will love it!” There’s probably some truth to that, but that is not a good enough reason. What exactly are you making accessible and why? Who are your API users – are they your customers, or third party services, or developers who are looking to extend upon your application for their customers? Understanding the market you are serving is vital to the success of any product or service.
Key questions to ask: