Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
We have all been doing “web services” forever. My first introduction was in the late 90’s with XML-RPC and WDDX. Followed up soon after with SOAP. Good times. Oh and remember WS-*. Don’t remind me.
Why?
Over the last couple years, I’ve really taken an interest in HTTP APIs.
I’ve been meaning to post about my experiences developing an HTTP APIs. It’s been an interesting last couple of years and I think there is quiet a bit to share.
Issues
I can only speak from my experiences and give some of the context about my situations. Hopefully you can relate and translate it to your own projects and make a determination if what I struggled with is beneficial in your context.
There were four major pain points that I ran into developing our HTTP API and Clients.
- Unable to change internal data structures that got exposed/serialized to Clients
- Unable to change endpoint paths/routes
- Endpoint documentation (incoming and outgoing payloads)
- Workflow logic living on the client
HTTP APIs
Sometimes all you need is to do CRUD. Sometimes that’s the last thing you should be doing.
Most examples and getting started tutorials usually demonstrate exposing your database structure and provide GET/POST/PUT/DELETE as away of performing CRUD.
You basically end up with HTTP endpoints that are a 1:1 mapping with a database entities.
This also makes it incredibly hard to change your API.
Go beyond serializing a database row into JSON
I’ve realized that developing an HTTP API is not much different than developing a regular HTML Website.
I started developing my HTTP APIs like I would if I were creating a static HTML or server side rendered HTML web application. This means bringing the concepts we’ve been using for ages with HTTP and HTML such as links and forms.
(Un)Surprisingly, this lead to several benefits. First, our API clients could consume our API with ease. Second, they became dumb. Workflow or business logic stayed on the server and didn’t leak to the client.
Series
This series of posts is going to cover some misconceptions I had in regards to HTTP APIs and REST.
Producing an HTTP API using Hypermedia and various media types.
Consuming an HTTP API that uses Hypermedia.
How you can use CQRS and Hypermedia together.
Similar to my Fat Controller CQRS Diet series, I’m going to convert an existing web application. Currently I’m thinking of using the MVC Music Store again. If anyone has any other suggestions or recommendations about this series, or the sample project to convert, please leave comment or let me know on twitter.
- Building a Self Descriptive HTTP API in ASP.NET Core
- Object as Resource
- Hypermedia
- Siren
- HATEOAS
- Hypermedia Clients
We have all been doing “web services” forever. My first introduction was in the late 90’s with XML-RPC and WDDX. Followed up soon after with SOAP. Good times. Oh and remember WS-*. Don’t remind me.
I am really looking forward to this series.
Thanks! Hopefully it lives up to expectations 🙂
It would also be interesting to see a comparison between a REST implementation, and a GraphQL implementation.
GraphQL is gaining traction these days, as a more flexible alternative to REST.
Single end-point.
Simpler versioning (you probably won’t even need it).
Client requests only the data it needs, and in the case of component based JavaScript libraries such as React, Vue, etc, you can keep the component and its queries neatly arranged ‘together but separate’.
Easier to mock a backend while developing a UI.
Subscriptions – real time data flows using web sockets.
I can’t speak for GraphQL but I can with OData. I may be way off base even comparing them, but if they are similar I can see it’s use case. However, it’s not so much about getting data or entities as about getting information and what actions you can perform. Meaning your API responses can be rich full of information for the clients like where they can navigate to next or what actions they can perform base on the current state.
I built a project who had a single /jsonrpc endpoint that accepted JSON-RPC 2.0 requests. It would then bind the request json payload by method name to a business layer command or query to be executed via MediatR handlers. The team loved it since it was so simple to add new commands to the business layer which knew nothing about the web front end at all. It would be relatively simple to add Swagger support as a way of documenting the API.
https://github.com/Command-R/CommanderDemo
Interesting. Looking forward to read the series.
A suggestion: How about convert Jimmy Borgard’s Contoso University (https://lostechies.com/jimmybogard/2016/10/21/contoso-university-updated-to-asp-net-core/ )? It looks *more* complex than Music Store.
Ya I thought about that. Thanks for the suggestion. I may take a really small sample application like the ASP.NET Core Docs Todo Web API app and then create a client frontend for it.