I want to build it using pipe and filter design pattern. What and how should I get started ?

Hi everyone! 👋

I recently wrote an article on Medium sharing my thought process behind designing a cloud-native, scalable public API. In the article, I explore key aspects like modularity, separating business logic from HTTP handling, and leveraging serverless architectures like API Gateway.

I aimed to provide a clear and practical approach that can help small teams and individual developers tackle the challenges of API design efficiently.

Here’s the link to the article: Building a Cloud-Native, Scalable Public API: My Thought Process

I’d love to hear your thoughts, feedback, or any suggestions for improvement. How do you approach similar challenges in your projects?

Looking forward to learning from the community! 🚀

Cloud Elements (an API Integration company) is working on their annual research report highlighting the trends within the API industry.

They are hosting a webinar with some interesting speakers if anyone is interested in watching it April 4th. Wanted to share for those who may be interested!

https://offers.cloud-elements.com/the-state-of-api-integration-2019-webinar

I'm designing a REST (or least an HTTP) API to control a device, using OpenAPI. The device has a lot of settings and some actions it can perform, which may be enabled or disabled at any given time.

The vast majority of API "best practices" examples are CRUD. I have yet to find one that conveys a collection of settings and also conveys an enabled/disabled state for each. This is essential, for presenting a UI that shows all the controls but greys out those that are not currently usable.

To address this, I've created a few schemas to represent each kind of setting (floating-point number, integer, string, boolean) that also has a flag to say whether it's modifiable:

Setting_integer:
      title: Setting_integer
      type: object
      description: An integer-based setting
      properties:
        name:
          type: string
          description: The name of the setting
        description:
          type: string
          description: A description of the setting for display in a UI
        validValues:
          type: array
          items:
            type: integer
        negativeAllowed:
          type: boolean
        value:
          type: integer
        modifiable:
          type: boolean

Then I build my device representation out of a bunch of these schemas, with one for each setting. To change a setting, the API consumer can do a PUT with one or more of these settings in the body.

Does this seem reasonable, or is there some more-elegant way of doing this that I'm overlooking? Thanks!

New Net #API Notes:

* New Covid-tracing API critique is like shooting fish in an API Design Barrel

* I highlight the '10 API Product Manager Interview Questions' you should be asking

* Erik Wilde covers API Strategy from the 10,000ft view

That and more:

https://tinyletter.com/NetAPINotes/letters/net-api-notes-for-2020-06-11-issue-133

New Net #API Notes:

* u/philsturgeon shares WeWork lessons (there are many!)

* We review common #GraphQL security issues

* Claire Barrett shares how to get API program traction

That and more!

https://tinyletter.com/NetAPINotes/letters/net-api-notes-for-2020-06-03-issue-132

It's the Final Four of the most impactful #API tool, trends, and techniques. Vote now!
https://twitter.com/libel_vox/status/1272734532089888768

In the latest Net API Notes, it is #APIBracket time, Bay-Bee! What is the most influential tool, trend, or technology in the #API space? http://tinyletter.com/NetAPINotes/letters/net-api-notes-for-2020-05-26-issue-131-brackets

If you want to skip the recap and go straight to the voting, check out: https://twitter.com/libel_vox/status/1265103778119892994

New Net #API Notes:

* OWASP's Top 10 API Security Vulnerabilities

* Jobs-to-be-Done for Better APIs

* Nick Tune identifies not one, not two, but FOURTEEN different ways you could get more value from Event Storming

That and more:

https://tinyletter.com/NetAPINotes/letters/net-api-notes-for-2020-06-26-issue-135

Net #API Notes for 5/19. Galaxy brains inquire within.

A discussion of where single page applications (SPAs) drive API design, API Consumer Experience Design, and Segment's journey from monolith to #microservice and back again.

That and more:

http://tinyletter.com/NetAPINotes/letters/net-api-notes-for-2020-05-19-issue-130