DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for How to Mock an API in ONE minute
Ismail Kamil
Ismail Kamil

Posted on • Updated on

How to Mock an API in ONE minute

Front-end developers usually meet this problem. The API is designed, but it's not been implemented yet. I need to make some fake data for my interface, which means I have to set up a mock server and add some response examples. If there are no response examples in the API documentation, I must make up some response data myself.

Each time I do this, I think it's not what a front-end developer should do.

There should be a better way to accomplish this.

I tried many tools. I used postman as a mock server, but all response data must be added manually. I tried faker.js, but I have to write mocking code for every field.

In my expectation, an excellent mocking server should generate data itself. Developers should pay attention to real essential things.

Great news: Now, you can mock an API in only one minute. And you don't need to write any scripts.

Why mocking

Mocking is a good choice if you're on one of the following occasions.

  1. The API is designed but not developed. This usually happens in agile teams.
  2. Restricted or paid APIs. For example, bank APIs. You cannot get real data before development completes. So you need mock data.
  3. Offline environment or intranet. Mock data allows you to work on a local machine.

Letβ€˜s Mock it

There are two steps to mock the API.

  1. Import API definitions.
  2. Get the mock URL.

So easy. Let's mock it!

Step 1 - Import API definitions

API documentation is necessary. OpenAPI (Swagger) is best, and any other format is OK, too.

Assume you have a YAML or JSON file. We’ll import it into this tool: Apidog. If you don’t have an API yet, you can also create it in Apidog.

1.Create a new project in Apidog.

Create project
2.Go to "Settings"-"Import", and drag your API file in.

Import API

More than ten formats of API documentation are supported. Click "Next" and your API will be imported.

Now you'll see the APIs in Apidog.

API imported

Step 2 - Get the mock URL

1.Click an API in Apidog. You'll see an API definition page, in which there is a Section named "Mock".

2.Click the URL in the "Local Mock" part which starts with "127.0.0.1" to copy it.

Mock URL

3.Paste it into your browser.

OK, it's done! You'll see a mocking JSON!

Mocking JSON

A "city" field is filled by a city name, an "id" field is filled by an integer, and "createdAt" is filled by a date-time.

Now you can use the API data in your App.

And you don't need to write any scripts! Data in all fields are generated automatically.

Moreover, if you click "reload" in the browser, the data will refresh!

Mocking JSON

Amazing.

How it works

The first time I found this feature, I was quite surprised. Why can Apidog generate this? I didn't set anything!

Later I found this.

Mocking rules

There is a batch of built-in mocking rules in Apidog, as above. If your field name in the response definition matches one of them, the field data will be mocked automatically.

And Apidog starts a mock server in your local machine automatically. So you don't need to do anything in the server layer.

What if you don't like the data it mocks automatically? That's also easy.

You can directly fill the mock value of the field with Faker.js like this.

Faker.js

All Faker.js grammar is supported so that you can select them easily.

And if some field has a fixed value, you can also fill the "mock" with the specified value.

Fixed value

Alright, all done.

I hope you mock happily with Apidog.

It's really a good tool. And I found it's not only good for mocking but for everything in API development.

Download Apidog here.

Top comments (14)

Collapse
 
marcobrandizi profile image
Marco Brandizi

It's really interesting, despite the fact things won't be so smooth in reality: an initial specification of how the API responses should look like is likely to change while it is developed for real. But the approach might be useful in having an early and clear-enough idea of what the API should return. Having to make a few changes later, either client or server side, is still better than having to redefine the API completely because important requirements were overseen.

Collapse
 
ismailkamil profile image
Ismail Kamil

Thanks for the reply. I wrote a new article to answer this question, in which I used your sentence.😁

Collapse
 
restdbjones profile image
Jones - codehooks.io

Hi, another approach is to use serverless API where you actually create the real API without the hassle of a server. And run your code against different backend spaces, i.e. mock/dev/stage/production.

codehooks.io/blog/how-to-quickly-c...

Jones

Collapse
 
akihikotkg profile image
Akihiko Takagi

Powerful. Front-end engineers should like it.

Collapse
 
ismailkamil profile image
Ismail Kamil

Yeah I believe so.

Collapse
 
kingdavidmiles profile image
david miles

sure indeed it really help

Collapse
 
prof3ssorst3v3 profile image
Info Comment hidden by post author - thread only accessible via permalink
Steve Griffith

Do you work for APIDog?

Collapse
 
govindappaarun profile image
Arun Kumar Govindappa

But sure its not a one minute thing

Collapse
 
rexcel profile image
RexcelWang

Looks great!

Collapse
 
arifpateldubaiprestonuk profile image
Arif Patel Dubai Preston UK

Thank You For The Information

Collapse
 
manuelbrs profile image
Juan Manuel Bello

Great, thanks for sharing

Collapse
 
fontanaricardo profile image
Ricardo Fontana

This tool is great for paid services and offline API, but in real scenarios the backend generates de Open API specification, if you don't have the API you don't have the specification.

Collapse
 
ismailkamil profile image
Ismail Kamil

In many companies backend developers design API first. So API specification comes out before API is implemented.

Collapse
 
alexelziere profile image
Alex Elziere

great

Some comments have been hidden by the post's author - find out more

Classic DEV Post:

Understanding git through images