Apa yang harus disebut API HTTP yang tidak tenang? [Tutup]


24

Apa yang Anda sebut API berbasis HTTP, menggunakan URI untuk memberi nama sumber daya dan kata kerja HTTP (PUT, POST, DELETE, DAPATKAN ...) untuk memanipulasi sumber daya itu?

Menurut keluhan Roy Fielding itu bukan REST, karena tidak ada hypermedia.

Secara internal, di tim saya, semua orang menyebutnya "REST API". Saya menyebutnya "REST-like" tetapi tidak deskriptif dan artinya tidak jelas. Saya cukup bingung tentang itu, karena ada perbedaan pendapat besar tentang REST. Saya tidak ingin ambil bagian dalam perang api, tetapi cukup gunakan istilah yang benar.


6
Berapa banyak waktu Anda di tempat kerja yang Anda habiskan untuk pemrograman, dan berapa banyak waktu yang Anda habiskan untuk memutuskan terminologi apa yang akan digunakan? Misalkan Anda merilis produk hebat tetapi Anda menggunakan terminologi yang sedikit salah dalam beberapa dokumen internal. Apakah pelanggan Anda peduli?
Brandin

3
Bagaimana Anda menyebutnya dan apa yang Anda sebut itu adalah dua hal yang berbeda.
JeffO

13
Apakah pertanyaan ini benar-benar menjamin snark dan skeptisisme dalam komentar? Tampaknya tidak masuk akal untuk menginginkan cara yang layak, dipahami secara luas untuk merujuk pada konsep tingkat tinggi yang cukup sering digunakan.
Ben Aaronson

6
@Brandin, kata-kata berarti banyak hal. Sampai saya dapat menghubungkan USB stick ke otak Anda dan mengunduh kode saya secara instan, saya harus menggunakan label dan terminologi untuk mengomunikasikan maksud saya. Jika saya mengatakan "SOAP HTTP API", itu akan berarti sesuatu yang sangat berbeda dari "REST HTTP API". Memberi penamaan adalah masalah yang sulit, dan juga penting.
Paul Draper

6
Bersiaplah untuk menyerah pada topik ini dengan tim Anda saat berikutnya Anda membicarakan topik ini dan mendapat perlawanan di atasnya. Saya adalah tipe orang yang menganggap penting bahwa kita menggunakan terminologi yang benar sehingga ada sedikit kesempatan untuk miskomunikasi; banyak orang tidak berpikir seperti ini dan bahkan akan menganggapnya sebagai serangan terhadap kecerdasan mereka jika Anda mencoba untuk mengevaluasi kata / pilihan teknis mereka, dalam hal ini hanya tidak sepadan dengan argumen. Jika Anda memiliki neurotik (atau lebih) di tim Anda dan mereka menolak gagasan bahwa mereka sebenarnya tidak melakukan REST, yang terbaik adalah menyerah begitu saja.
Ravenstine

Jawaban:


43

Sebut saja API HTTP .

Ini sesuai dengan standar HTTP, dan tidak memiliki apa pun yang berlapis di atas (mis. SOAP).

Standar HTTP menentukan sumber daya, kata kerja, tajuk, negosiasi konten, dll.

REST (REpresentational State Transfer) adalah arsitektur dengan persyaratan yang sesuai dengan standar HTTP yang ada, tetapi HTTP bekerja dengan sendirinya.


Dalam pengalaman saya, 90% dari "REST HTTP APIs" harus menyebut diri mereka "hanya" sebuah HTTP API.

Jangan malu untuk meninggalkan label REST. Seperti halnya layanan-layanan microservice dan non-relasional, Anda tidak perlu memiliki API yang tenang untuk menjadi keren. Roy berangkat untuk menciptakan arsitektur aplikasi jaringan yang berumur paling lama, paling kompatibel, dan terbelakang yang dia bisa. Dia melakukan pekerjaan dengan baik. Tetapi tidak semuanya membutuhkan kompatibilitas 40 tahun.


6
"Dalam pengalaman saya, 90% dari" REST HTTP APIs "harus menyebut diri mereka" hanya "sebuah HTTP API." +1
Artur Gaspar

Saya sangat setuju. Di mana saya saat ini bekerja, kami membangun UI klien-server yang canggih menggunakan kerangka kerja aplikasi terdepan dalam siklus pengembangan yang cepat. Tidak ada yang tenang tentang hal itu; kami hanya menggunakan POST. Itu tidak trendi, tetapi itu menyelesaikan pekerjaan, dan menyelesaikannya dengan sangat baik. Ini beberapa kode terbersih yang pernah saya lihat.
Robert Harvey

19

Richardson Maturity Models seperti ini

  1. POST di mana-mana. Satu titik akhir. (SABUN MANDI)
  2. POST di mana-mana. Beberapa titik akhir. (sumber daya)
  3. KATA KERJA HTTP. Beberapa titik akhir.
  4. Suka 2 dan kembalikan tautan ke sumber daya. (Tenang)

Jadi menurut model saya akan menyebutnya layanan web yang sesuai dengan richardson level 2 atau sesuatu seperti itu.

http://martinfowler.com/articles/richardsonMaturityModel.html


8

Hypermedia tidak pernah benar-benar menjadi populer dengan API seperti REST - sampai pada titik ketika API benar-benar mengimplementasikan navigasi hypermedia, istilah RESTful tidak cukup untuk membedakannya dari API web "RESTful" lainnya. REST telah menjadi istilah umum atau semua API web berbasis sumber daya dan nama baru seperti Hypermedia API  telah diciptakan untuk fokus pada konsep hypermedia.

Saya tidak benar-benar ingin menganjurkan penggunaan istilah yang salah, tetapi saya pikir bahwa interpretasi umum modern REST hanya berarti menggunakan URL yang seragam dan kata kerja HTTP untuk kebanyakan orang. Itu tidak benar, tetapi siapa pun yang tahu definisi Fieldings, juga harus tahu bahwa banyak orang lain tidak. Di sisi lain, siapa pun yang mengetahui REST hanya dengan mengamati bagaimana API "RESTful" yang ada diimplementasikan, tidak akan tahu apa yang Anda bicarakan ketika Anda menyebutkan kendala REST yang kurang dikenal seperti HATEOAS atau kode sesuai permintaan. Fielding mungkin tidak menyukainya, tetapi saya pikir sudah terlambat untuk kembali ke definisi asli *. Dan mari kita jujur: Jika Anda mendengar seseorang berbicara tentang REST API-nya untuk pertama kalinya, Anda langsung menganggap itu tidak termasuk hypermedia, bukan?

Bersikeras pada definisi RESTful yang benar biasanya hanya menciptakan kebingungan tambahan. Seperti halnya banyak istilah yang telah mengubah maknanya dari waktu ke waktu atau bahwa massa hanya salah mengadopsi, saya menghargai jika seseorang mengetahui definisi asli tetapi saya tidak akan memperbaiki siapa pun yang menggunakan interpretasi modern REST yang lebih luas.

* dan juga terlambat untuk menetapkan persyaratan baru untuk API non-hypermedia seperti REST, dalam hal ini. Bagaimana kita harus memanggil mereka? ... tenang ?


1
API Github memiliki banyak hypermedia. Saya tidak tahu bagaimana tipikal itu. Saya setuju dengan Anda bahwa istilah 'RESTful' telah lolos dari kendali Fielding untuk merangkul lebih banyak hal.
dcorking

2

Ini adalah antarmuka CRUD (Buat, Baca, Perbarui, Hapus) melalui HTTP.

Saya tidak bisa memikirkan otoritas yang mendukung pernyataan ini, jadi saya harap Anda mendapatkan jawaban yang lebih banyak dan lebih baik.


4
Sesuatu yang tenang juga cocok dengan definisi itu.
Blrfl

1
@ BLFL AFAICT Beberapa APIS yang tenang akan menjadi superset dari ini. Itu tidak akan memenuhi definisi Fielding jika catatan tidak mengandung hyperlink.
dcorking

2

Anda dapat menyebutnya apa pun yang Anda suka, orang cenderung (hampir secara religius) menempel pada bagian mana pun dari 'spec' REST yang tidak Anda ikuti dan menggunakannya sebagai titik protes yang sangat merugikan perkembangan. Namun demikian, fakta sederhananya adalah ada (hampir) nol layanan yang menerapkan REST sejati untuk layanan API mereka.

Di tim kami, kami menamai milik kami Stateless APIsaat itu sedang dalam pengembangan karena kami memiliki warisan API SOAP Stateful dan Fungsional yang kami ganti (API warisan itu sendiri tidak pernah memiliki nama yang disepakati dan bermakna baik sehingga kami tidak terlalu terjebak dalam nama ).

Sekarang proyek ini hanya memiliki satu API the <project> API. Ketika kami akhirnya menggantinya, API baru hanya akan dikenal sebagai the new <project> API.

Memberinya nama yang mewah dan deskriptif hampir tidak ada artinya kecuali Anda memiliki begitu banyak API sehingga Anda perlu membedakan ini dari yang lain (dalam hal ini Anda mungkin harus mengganti nama yang lain juga).


Meskipun pertanyaan awalnya buruk, jawaban ini adalah upaya yang solid untuk menjawab pertanyaan
Michael Shaw

2

Anda bisa menyebutnya API Web . Ini adalah istilah yang sangat luas tetapi dapat menghindari nitpicking tentang arti definisi tipe API lainnya. Istilah ini kurang teknis dan tepat dibandingkan dengan alternatif seperti HTTP API , tetapi itu mungkin menguntungkan ketika berbicara dengan orang-orang non-teknis.

Istilah ini juga digunakan oleh Leonard Richardson (yang mendefinisikan Richardson Maturity Model yang sudah disebutkan jawaban lain - pengukuran yang diterima dengan baik untuk seberapa dekat API dengan arsitektur REST). Ini adalah apa yang Anda dapatkan jika Anda membuang bagian "RESTful" dari " RESTful Web API ".

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.